Functions throwing exceptions

[mike-wheel]

Hi! As a functional programming advocate, I really like the date-fns/fp module. I can pick just the function that I need, and it works well within my function compositions!

However, the fact that the functions throw exceptions is a bummer 😞. We had some code like format("MM/dd/yy", new Date(date)). It was working great until our backend provided an ISO date that was malformed, and the entire page crashed because format throws if date is an Invalid Date. Of course, the ways to prevent this is to be more defensive in checking the date (eg, isValid), or to wrap everything in a try/catch, but that's not quite aligned with the principles of functional programming.

I'm curious how people deal with this? Just resign to using try/catch? Wrap the functions with other ways of handling errors (Result monad, etc)?

I'm also curious if there has been any discussion about having date-fns use alternate ways of error handling that doesn't throw and require try/catch. Other libraries will more gracefully return Invalid Date or similar which is less likely to affect other parts of the code (and crash the page, as in our case).

Now that date-fns uses typescript, functions that would otherwise throw could now return errors as a union with the return type. For example, format might return a string | { type: "error", message: "Invalid Date" }. The type system would enforce that the consumer handle these runtime errors at compile time. Something like this might be automatable in convertToFp to wrap in a try/catch and return something else in the case of an error.

Any ideas or insight would be greatly appreciated!

[kossnocorp]

Hey!

I'm glad you wrote this because it was also bugging me but for another reason. In v3, we removed all exceptions, argument number checking, interval correctness, etc. In most cases, people get Invalid Date or NaN, which feels the most native to JS, and it removes a lot of boilerplate code and reduces the minimal size of the bundle.

For the most part, it's expected as the input is not static, and nobody wants users to break apps because they entered something wrong.

With parse and format functions, I couldn't decide as I still wanted to let developers know that they used the wrong tokens format. In such cases, getting an Invalid Date is very confusing and might lead to a long debugging session.

Another issue with parse is that a string is expected, and there's no invalid string in JS, at least natively.

So, I decided to keep the v2 behavior as is, including the invalid date exception.

---

I like the idea of having an error type. It seems easy to implement. This also could be extended to NaN and Invalid Date results of other functions that don't have exceptions. What do you think about that?

In v4, my plan is to extract all I18n functions and locales into separate packages, i.e., @date-fns/en-AU, so maintainers can update and ship them separately. In the same fashion, I considered extracting @date-fns/fp, so there will be a chance to improve many things like that.

[kossnocorp]

Created an issue for tracking the progress: #3657