Pierre A. Duchateau

Hi @Chuckytuh, thanks for opening this discussion. I don’t use generators personally but here is my interpretation: the `Result` type needs to be unwrapped where the value is required. In...

If the consumer expects an exception for the normal case, then it’s totally fine to throw an exception to comply. ´Result’ are useful to have typed errors, meaning the consumer...

You can see how `superthrow` implements it in their [ResultAsync](https://github.com/supermacro/neverthrow/blob/master/src/result-async.ts) type.

@slavovojacek From my point of view, the only advantage of `Result` is that errors are typed. If you don't care about the error type, you can do everything with plain...

Hello @unknown1337 you can use https://github.com/supermacro/neverthrow#resultasyncandthen-method cheers

Hello @cjroebuck This is how I proceed ```ts (req, res, next) => { loadUser(req) .andThen(validateUser) .andThen(lookupCache) .andThen((cache) => { if(cache) return Ok(cache) return validateOptions() .andThen(doSomethingExpensive) .andThen(putInCache) }) .match(result=>{ res.send(200,{status:"ok",result}) },err=>{...

I might be missing something but what does this achieve that .match() can’t ?

@ehaynes99 Thanks for this ! I think this proposal merits a PR ! Could you do it ?

Hello @0xksure .match() is meant to be used primarily as a method to **unwrap** a Result, in which case any behavior for value/error cases would be inside the callbacks. Maybe...

@0xksure I’m not sure what you are trying to achieve. If you have a Result and want to return an Err if the Result is an Err, then you should...