musicq

7 ms·

1.
by musicq 3y ago
Thank you for the suggestion! I will add that.
2.
by musicq 3y ago
I think the most usual way in a project is to use this style. Wrap is a simple way to let you get Result type without refactoring your implementation. https://musicq.gitbook.io/unwrapit/recipe/return-result-with...
3.
by musicq 3y ago
try/catch has no problem, but the premise is that you know there will be errors been thrown. Say a function `divide`, you can barely tell that whether it will throw errors or not without looking into the source code.
4.
by musicq 3y ago
The thing is not using try/catch, like the first case, sometimes you don't know if a function will throw or not. You can't tell from the function signature as well. So this provides a way that told you the function you called
5.
by musicq 3y ago
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
6.
by musicq 3y ago
Don't think would affect performance. The core function `wrap` is just try catch under the hood. https://github.com/musicq/unwrapit/blob/d5c437a235ad1f5ad042...
7.
by musicq 3y ago
Actually rxjs is a `peerDependency` which means it will assume the user will have it installed already.
8.
by musicq 3y ago
Spent sometime to complete the document of my rust Result like library `unwrapit` for JS/TS. Still think this might be a proper way to deal with errors in JS/TS
9.
Unwrapit provides a way to handle errors in JS/TS(musicq.gitbook.io)
50 points by musicq 3y ago|70 comments
10.
by musicq 4y ago
reprint
11.
Rust Result type mimic in TypeScript(github.com)
1 points by musicq 4y ago|2 comments
12.
by musicq 4y ago
Use Rust Result types in TypeScript to handle errors easier in both sync/async functions.