-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify semantics of OK.try rescue clause #42
Comments
Always approve more clarity in the docs 🐳 |
Did you want to add anything to the docs for this? |
I just saw this library in Elixir Radar, and I also found the "rescued" part confusing. @CrowdHailer I think you should've picked a different word, as people might get confused as to whether the "rescue" part will capture runtime errors and other exceptional errors as the regular try/rescue does. Perhaps: OK.try do
after
except
end would've been clearer. That's just me. Other than this the library seems cool! |
@walkr However if there is anything you think could be clearer as a beginner to the library please do open a PR. even one sentence in the docs might help someone. I'm quite along way from having by beginners hat on with this library so am probably not the best person to do it. |
@CrowdHailer Ah okay, got it! Thanks for the explanation. |
I think it's worth it to make it clearer in the docs what happens in the "unhappy path" in
OK.try
- the wrapped errors get unwrapped and "rescued", but non-tagged errors cause a runtime error.For example the first test case will succeed, but the second one will fail:
For more clarity it might be worth adding that
safe_div/2
used in all examples returns{:ok, integer()} | {:error, atom()}
, so in the division by zero case it will return{:error, :zero_division}
, not:zero_division
The text was updated successfully, but these errors were encountered: