I haven’t used Rescript in a large system yet.
Are you still using JS exceptions? What’s your rate of exceptions?
If I use Rescript, I would expect that our APIs move away from propagating exceptions to returning Results. Is that a reality or good standard for both green and older apps?
Example:
We use middyjs as our aws lambda middleware lib. We throw exceptions thats are then caught and decorated with the correct meta data to return back to our client.
On a 3rd round of iteration, perhaps it’s best to convert the Result / Left back to a JS exception to reuse our error handling middleware
There’s no requirement either way. ReScript is pragmatic, you do what you need to, to ship your product.
If you have a good exception handling middleware that you want to reuse, that seems like the most important consideration. Another way to do it would be to use result<'a, exn> to make sure nothing actually throws an exception, but then you’d need to propagate these types throughout your system, it would likely be a big refactor.
Another option is to try reanalyze’s static exception analysis, which can warn you about unhandled exceptions: reanalyze/EXCEPTION.md at master · rescript-association/reanalyze · GitHub . By comparison it is much more lightweight than propagating types throughout your system (just requires a @raises attribute on top of functions which can raise or propagate exceptions).
5 Likes