Errors in javascript are not easy for maintainers and users of libraries. While currently, the project is still relatively small and every error can be described by documentation, as the project grows it makes it more and more difficult to understand what's happening. This is not because of a lack of documentation, but rather that errors in TypeScript can't be declared in the typical sense - anything can be thrown by any method and catch the user off-guard.
As an alternative, we could provide the users with "Errors as Values", where we return Results and Options instead. This makes possible errors and empty values explicit and gives the user complete knowledge and control over them. If the user doesn't want to deal with the error-case, they can just unwrap these values.
One possible library for this implementation is oxide.ts, but other alternatives exist as well.
Errors in javascript are not easy for maintainers and users of libraries. While currently, the project is still relatively small and every error can be described by documentation, as the project grows it makes it more and more difficult to understand what's happening. This is not because of a lack of documentation, but rather that errors in TypeScript can't be declared in the typical sense - anything can be thrown by any method and catch the user off-guard.
As an alternative, we could provide the users with "Errors as Values", where we return
Results andOptions instead. This makes possible errors and empty values explicit and gives the user complete knowledge and control over them. If the user doesn't want to deal with the error-case, they can justunwrapthese values.One possible library for this implementation is
oxide.ts, but other alternatives exist as well.What do you think?