Handling your logic with composable functions makes your code declarative, leading to code that's easy to read and easy to test. Breaking that up to wrap some risky function in a
try/catch block introduces imperative code and makes it harder to maintain that declarative approach. With Ramda's
tryCatch function, you can handle errors right in the middle of a composition and leave your code clean and functional. We'll also see how you can use
propOr to avoid common "cannot find X of undefined" errors.
[00:00] We've included the Ramda library, created a person object with a name property, and I have some code that gets the name property and logs it out. Now if I jump to the terminal and run this, we'll see that our name property gets logged out, and everything's working as expected.
[00:12] Now let's say I want to use this in a pipeline. I'm going to define a new function that I'll call getUpperName, and I'm going to set this equal a call to R.pipe, and we're going to pipe our getName function into R.toUpper, and then I want to change my result to be a call to getUpperName.
[00:31] I'll save that, I'll switch over to the terminal, run it, and we should get our name in all caps.
[00:40] We have everything working as expected, we get the name property off of our person, we pass it to upper, and we get a result. But what if we ended up with some undefined value getting passed into our getUpperName? If I run this again, we're going to get a type error, because the property name can't be found on undefined.
[00:59] We could pull getName out of the pipeline, wrap it in a try catch and handle the potential error that way, or we can use Ramda's tryCatch function. For that I'll come up here to getName, and I'm going to put a call to R.tryCatch, passing it R.prop as the first argument.
[01:17] The second argument is also going to be a function, and this is a function we want to run in the case of an error. What we can do here, is we can say R.always, and we can return a default value that'll then get piped into toUpper.
[01:31] I can save this, jump back into the terminal, run this, and this time I'll get back that default value and we'll see that it's been piped through toUpper. Of course, if I come back down here and replace this undefined with an object that has our name property, and run this again, we'll see that it works as expected when there's no error.
[01:51] I should point out that I used R.prop here to demonstrate how tryCatch works, but since this type of error is pretty common, there is a convenience method to do this very thing already included in Ramda.
[02:03] I can come up here, and I'm just going t comment this out, and I'm going to redefine getName. This time I'm going to use prop or, and I'm going to provide our default value first, followed by the property I'd like to get. I'll save this, switch back into the terminal, run it, and we'll see that we still get our name piped through toUpper, but if I come back in here and I replace person with undefined, we'll get our default value.
@Sébastien: good point, and I believ that this error throwing was a bug.
propOr should now work like
pathOr and respond with an
undefined instead of a new error when given bad data.
Maybe due to an evolution of the library (I'm using "ramda": "^0.25.0") The
propfunction doesn't raise error when provided
undefinedor an object with an undefined targeted property, so the
tryCatchwon't catch anything. And the error will occur on
Here is a working example:
const getName = R.prop("name") const getUpperName = R.pipe( getName, R.tryCatch(R.toUpper, R.always("DEFAULT")), )