dry-monads

dry-monads copied to clipboard

While I like the idea (we're considering using monads in our project and need the same feature), the name of the method is quite confusing to me. Having failure! as a conclusion of the method call isn't what you usually expect. Maybe something like value_or_fail! or value_or_raise! could work here.

Apr 29 '20 08:04 hwo411

I was not convinced with failure!. I sent it before the discussions in Zulip. I like value_or_raise!, would that one work ?

Apr 29 '20 15:04 bilby91

@hwo411 Updated!

Apr 29 '20 20:04 bilby91

@hwo411 +1 for value_or_raise! name

May 05 '20 13:05 davydovanton

Any interest on getting this one merged ?

Jun 17 '20 15:06 bilby91

Bump!

Nov 17 '20 19:11 bilby91

@bilby91 sorry for this delay. I don't think it's a good idea to have it as it is because it assumes there's an exception in Failure. It's not always the case. It's more suitable for the Try monad, wdyt? Apart from it, I wouldn't mind having it as an extension, though.

Nov 22 '20 12:11 flash-gordon

@flash-gordon You make a great point around failures potentially being something different than an error. Can you provide some extra insight on your thought about adding this to the Try monad please ?

Thanks!

Nov 28 '20 15:11 bilby91

@bilby91 two steps

1. You just add value_or_raise to Try's Value and Error instead of Result.
2. a. In your code, you use Value instead of Success and Error instead of Failure. And also include Dry::Monads[:try, :do] instead of include Dry::Monads[:result, :do]. b. Alternatively, you add Success#to_try/Failure#to_try similarly to how #to_success/#to_failure for Try->Result conversion. Then in the place where you want to call .value_or_raise you do result.to_try.value_or_raise.

Feel free to ask, I can do it myself.

P.S. Note value_or_raise shouldn't have ! at the end because according to ruby guidelines it should only present when there's an alternative, "safer" version of the method: fetch! vs fetch etc.

Nov 28 '20 16:11 flash-gordon

My team has been looking for similar behavior, so I wanted to check in on the status here.

One small additional piece that we've implemented in our current workaround is to copy the trace over from the Failure to help provide additional context:

def value_or_raise
  error = StandardError.new(failure)
  error.set_backtrace(trace)
  raise error
end

Would be great to see this in the project (happy to help / open an alt PR if preferable). Thanks for the fantastic project!

May 11 '22 21:05 christoomey

This would be a great addition... this UnwrapError makes little sense practically. At least we should have the option to reraise the original error or turn anything not an error into to string and raise it...

Aug 24 '22 16:08 jp30566347