musicq
Re:A better way to handle errors in JavaScript
on Tuesday October 31, 2023 @07:38AM (#38083238)
Thank you for the suggestion! I will add that.
Re:A better way to handle errors in JavaScript
on Tuesday October 31, 2023 @07:37AM (#38083222)
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...
Re:A better way to handle errors in JavaScript
on Tuesday October 31, 2023 @07:35AM (#38083209)
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.
Re:A better way to handle errors in JavaScript
on Tuesday October 31, 2023 @07:29AM (#38083152)
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 might throw. It's more like an alert before a crash.
[res, err] is good, actually I used this style for a long time. `unwrapit` is a nicer way to let you write [res, err], like type hints and other utility methods.
Re:A better way to handle errors in JavaScript
on Tuesday October 31, 2023 @07:09AM (#38082956)
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.
https://musicq.gitbook.io/unwrapit/recipe/return-result-with...
Re:A better way to handle errors in JavaScript
on Tuesday October 31, 2023 @06:20AM (#38082578)
Don't think would affect performance. The core function `wrap` is just try catch under the hood.
https://github.com/musicq/unwrapit/blob/d5c437a235ad1f5ad042...
Re:A better way to handle errors in JavaScript
on Tuesday October 31, 2023 @06:06AM (#38082471)
Actually rxjs is a `peerDependency` which means it will assume the user will have it installed already.
Re:A better way to handle errors in JavaScript
on Tuesday October 31, 2023 @01:29AM (#38080689)
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
Re:Rust Result type mimic in TypeScript
on Friday March 17, 2023 @10:08PM (#35205355)
reprint
Re:Rust Result type mimic in TypeScript
on Friday March 17, 2023 @01:05PM (#35199839)
Use Rust Result types in TypeScript to handle errors easier in both sync/async functions.