You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it looks like Left values can be returned only by doing throwE. If I'm pursuing a functional approach, where errors are truly for exceptional cases, I would rather avoid going through the intermediate step of raising an error just to map to a Left value. Additionally, there are cases where a Left is not the result of an error thrown. For example, validation.
class-validator, and many other validation packages will already return something like a result object. Currently, I would have to do something like this:
I would rather simply have a helper left that I can return. It seems like this would also make code flow more consistent, since throwE throws, thereby interrupting other code, which decreases readability.
In JS, there is a performance penalty for throwing anything. This is especially true for Error types, because of stack generation, but is still true for other throwables.
The text was updated successfully, but these errors were encountered:
I assume your example code is ran inside the EitherAsync constructor. If you're using async/await the code is supposed to look procedural on purpose. I think you would find using EitherAsync without syntax sugar more elegant (i.e. with map, chain and all of the other utility methods).
Regarding the performance aspect of things, I agree and I would not recommend using purify for performance-critical applications, especially for async code, as the abstractions provided by the library are quite costly. That's not to discourage people from using the library, I mean it in the sense that if you really care about performance I wouldn't recommend neither purify nor JavaScript as a language.
Currently, it looks like Left values can be returned only by doing
throwE
. If I'm pursuing a functional approach, where errors are truly for exceptional cases, I would rather avoid going through the intermediate step of raising an error just to map to a Left value. Additionally, there are cases where a Left is not the result of an error thrown. For example, validation.class-validator, and many other validation packages will already return something like a result object. Currently, I would have to do something like this:
I would rather simply have a helper
left
that I can return. It seems like this would also make code flow more consistent, sincethrowE
throws, thereby interrupting other code, which decreases readability.In JS, there is a performance penalty for throwing anything. This is especially true for
Error
types, because of stack generation, but is still true for other throwables.The text was updated successfully, but these errors were encountered: