I've come to the conclusion that such a library offers little benefit in languages which embrace exceptions.
You have to basically wrap everything, making the code hard to read, and without proper ADTs and pattern matching it's easy to forget handling all cases.
There's also no way to prevent ppl from falling back to exceptions, so now you have a mess of exception and result handling.
And bc there is no blessed way, bigger projects typically include multiple different, incompatible result types.
One of the advantages of libraries such as these (in my opinion) is it gives you the ability to incorporate the errors thrown into the return type of functions, creating a broader contract than you would ordinarily achieve.
This is mainly in the context of TypeScript (think IntelliSense, etc.), also considering the fact that TypeScript doesn't support typed errors (neither does Flow, FWICS).
A fun example of this is Nim: “results” is quite a nice library, but Nim’s stdlib and by extension most of its third party libraries are built around exceptions (or std/options).
And Nim uses effect tracking, you can encode the exceptions raised into the type signature, so in some ways it’s perfectly poised for something like “results” or unwrapit
Yet when you try to go down that path (like we did at work, doing embedded firmware) it feels like you’re fighting against the current, sadly.
I personally like the saying „when in rome, do as the romans do“. While you CAN retrofit almost anything to a lang, it tends to be a constant fighting against the current which is rarely worth it.
A good example is when working with Qt, trying to avoid QString and QObject as much as possible is a fools errand, its slower and ultimately ends up with ugly code.
This library provides a way to encapsulate errors into a Result type, so that any user want to retrieve the value, they must unwrap the Result first. In this way I think it will force people to realize that there will be errors, you need to handle them. For JS users, you need to call _result.value_, for TS, the editor and compiler will warn you.
In my opinion, it never tries to prevent people from handling exceptions using try/catch, instead, it enrichs the error handling solutions.
`wrap` function is just a simple way for users to adopt this Result type quickly. I think in projects, developers should create their own Result usually, can check this example.
You are talking about a larger fundamental problem; code quality.
This library can be a way to handle errors just as the try/catch block is. If agreed on within the team ofcourse.
You have to basically wrap everything, making the code hard to read, and without proper ADTs and pattern matching it's easy to forget handling all cases.
There's also no way to prevent ppl from falling back to exceptions, so now you have a mess of exception and result handling.
And bc there is no blessed way, bigger projects typically include multiple different, incompatible result types.