musicq

Joined 6 years ago

Karma

Submissions

Member since

Mar 26

View on Hacker News

Recent submissions

Comment · 3 years ago

Thank you for the suggestion! I will add that.

Comment · 3 years 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...

Comment · 3 years 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.

Comment · 3 years 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 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.

Comment · 3 years 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 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.