0

I moved this question to softwareengineering.stackexchange.com because it better fits there.

I was watching the following video by Vladimir Khorikov, which recommends to "Refactoring Away from Exceptions" pluralsight.com - Applying Functional Principles in C# - Refactoring Away from Exceptions and instead using a Result object. You can also find a blog about it here: enterprisecraftsmanship.com - Functional C#: Handling failures, input errors

To summarize it, the recommendation is to prefer returning a result object then throwing an exception. Exceptions should be used to signalize a bug only. The arguments for this approach are the following:

  • Methods which throws exceptions are not "honest". You can't recognize if a method is expected to fail or not, by looking at its signature.
  • Exception handling adds a lot of boiler plate code.
  • When exceptions are used to control the flow, it has a "goto" semantic, where you can jump to specific line of code.

On the other hand return values can be ignored (at least in C#), which exceptions can not.

Is it a good idea to refactor a existing enterprise application in this direction? Or is a less radical approach the better one? (I belive that it make sense for sure to avoid Vexing exceptions by using return types for method like ValidateUserInput(string input))

Jonas Benz
  • 503
  • 3
  • 12
  • 1
    These are great questions, but the only answers would be opinions. This would be a better question for [Software Engineering](https://softwareengineering.stackexchange.com/). – Scott Hannen Jul 16 '19 at 16:13
  • Thanks for the remark, I moved it here: https://stackoverflow.com/questions/57060968/are-result-objects-the-cleaner-way-to-handle-failure-then-exceptions – Jonas Benz Jul 17 '19 at 08:10

0 Answers0