Hacker News Reader

musicqon Unwrapit provides a way to handle errors in JS/TS

Thank you for the suggestion! I will add that.

musicqon Unwrapit provides a way to handle errors in JS/TS

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...

musicqon Unwrapit provides a way to handle errors in JS/TS

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.

musicqon Unwrapit provides a way to handle errors in JS/TS

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.

musicqon Unwrapit provides a way to handle errors in JS/TS

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...

musicqon Unwrapit provides a way to handle errors in JS/TS

Don't think would affect performance. The core function `wrap` is just try catch under the hood.

https://github.com/musicq/unwrapit/blob/d5c437a235ad1f5ad042...

musicqon Unwrapit provides a way to handle errors in JS/TS

Actually rxjs is a `peerDependency` which means it will assume the user will have it installed already.

musicqon Unwrapit provides a way to handle errors in JS/TS

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

musicqon Rust Result type mimic in TypeScript

reprint

musicqon Rust Result type mimic in TypeScript

Use Rust Result types in TypeScript to handle errors easier in both sync/async functions.