Skip to content
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

Railway vs. Exceptions #3

Open
dlazerka opened this issue Jan 20, 2021 · 1 comment
Open

Railway vs. Exceptions #3

dlazerka opened this issue Jan 20, 2021 · 1 comment

Comments

@dlazerka
Copy link

Hi Scott,

It's more of question than an issue.

I couldn't stop thinking that with propagating error results using railway, we're basically reinventing exceptions. With two main differences:

  • We have to propagate exception up the stack manually.
  • We lose the very handy feature of exceptions -- stacktraces. In large projects it's often hard to track where an error came from (e.g. "DB timeout" error due to slow query -- which query was that).

Can we get our stacktraces back with Railway? The only way I see is to have "cause" field at each exception, and wrap them errors manually before returning (with some custom differentiator aka "line number").

@swlaschin
Copy link
Owner

I agree with your points! In fact I wrote a whole post about when NOT to use Results :)
https://fsharpforfunandprofit.com/posts/against-railway-oriented-programming/

In short, use Result for domain modeling and use exceptions if you need diagnostics. Hope that helps!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants