"Don't Throw Exceptions, Use A Result Pattern" is BAD ADVICE!

[@steve-wright-uk]

Our coding standards are that exceptions should not be used as flow contol. If we throw them then they should be cauught, logged and the current request terminated. If we want logic that says "if success do this, but if error do this" then we use a result pattern. We also use the result pattern for instances where the problem is tha fault of the caller and not a code fault in this program. For example if we are passed a filename to open and process, but find that the file has a virus then we'll use the result pattern to tell the caller we couldn't process due to ...

[@pilotboba]

Use exceptions for exceptional things. An invalid object posted to your API is NOT exceptional. It is an expected code path. (for example)

[@HamzahAudeh]

Thanks for the video. Actually I'm a big fan of the exception pattern (despite the continuous debate). I use custom exception even to handle the validation errors and the flow control of the system. This is a straight- forward approach and keeps domain logic more focused on the business, and in the global exception handler, I extract the status code with the message and any other related details and return a formatted response to the clients without having to deal with checks at each layer. I used this a lot on enterprise level systems and all things are fine.

[@sob515]

You don't get exceptions support on every architecture and platform. Result pattern is much more flexible especially on embedded systems. Exceptions are cool and easy until you get into real issues like the memory crashdump where stack or exception frames are corrupted which often happens in real world. Result pattern is also much easier and faster to debug at assembly level than having to deal with multiple exception handlers.

[@Codewrinkles]

You got a point here and I missed that. Like in all my videos I'm talking mostly from the perspective of developing systems based on REST APIs, gRPC and so on. My experience in embedded programming is close to 0. Thanks for pointing this out.

[@AndreyAndreev-Narf]

The "edge case" of using exceptions for flow control is a very, very common practice. People map exceptions to specific http response codes, and use this mechanism to avoid dealing with anything but their "happy" path in web applications. The advice to use result pattern largely targets this antipattern, not error handling in its entirety.

[@xybersurfer]

i think this is very well said. i can't stand the result pattern for these reasons. sometimes a framework forces one into using the result pattern in a language that doesn't support it. i'm assuming you also carefully consider when you use the result pattern

[@thiagocrabi4891]

Nice content Dan !! Keep up with the good work !

[@Codewrinkles]

Thank you. I'll try my best to keep it up

[@myPrzeslaw]

Result Pattern isn't an alternative to the Exceptions. At best it's an alternative to catch-blocks. Unhandled errors are still need to be thrown. Result Pattern is merely a convention separating desired (successful) path from expexted-error handling. It should never silence unhandled ones.

[@user-dc9zo7ek5j]

Thank you for the continuation. Although the result pattern comes from a functional background, its implementation in OOP languages is the very essence of good OOP and how it forces the code to be from typeless to strongly typed.

[@Codewrinkles]

I actually agree with that. I really think that most functional features added to C# actually make it a better OOP language.

[@robsonfaxas]

Right now I'm working in a Console application, and I throw exceptions from the farest layer to the client with a reasonable message and type, but the original exception is thrown in a more appropriated place (event viewer, error files, azure, depending on what I have in hand). This way I give a proper message to the UI and the stack-trace is not lost, it's kept in a hidden place for people to investigate if needed.

[@Codewrinkles]

I think your approach is very similar to what I discussed in the previous video. I also think it's a good idea to throw exceptions in the farthest layer.

[@someidiotwithnoname]

Depends on what I am building. If I use a repository pattern and have small application that is not logic heavy I use a try catch finally in my repository and use a Result pattern to handle success or failure but in logic layers I avoid throwing when an if can provide an alternative path to return success or error with details. As for dogmatic approaches, spot on. There are many dogmas in software development not all of them are wrong all of the time not all of them are correct all of the time. Acting like one shoe fits all is not a good sign.

[@TheMachina42]

Hard disagree, Exceptions are not supported on all hardware, they are inferior in their ability to be debugged, and most language that uses them have terrible implementation of them, Error as values, often are explicit in the function signature, in languages like Zig, you are forced to handle those errors. Exceptions are never used properly, they don't play nice with debuggers, they unwind the stack like it's nobody's business, and they will. The only reason they are as performant as they are is because LLVM is built for C/C++ semantic and optimized for it, the day LLVM or any other languages backend start optimizing for errors as value, they will truly be no reason to use exceptions.

[@debtpeon]

I'm surprised there is no mention of ADA. ADA is used by the military and exception is a mainstay of the language.

[@knkootbaoat6759]

to me the benefits between one or the other is greatly dependent on the context (problem domain, what you're trying to achieve, environment , etc etc) so the answer of which is better in this case is the classic it depends.

[@thewelder3538]

Maybe it's because English isn't your first language, but do you know what the word Exception actually means? An exception is NOT a general failure. An exception is just as it says, Exceptional. It is something beyond normal error handling. You should use exceptions ONLY when absolutely necessary and never at any other time. Now I could go onto a very long explanation as to why this is the case, but it's not my job to be educating you. What I have a problem with is the misinformation that you're spreading. So please, just stop it.

[@Codewrinkles]

There's no misinformation in this video. I'm certainly not in need of any education on this topic at least. But thank you for your feedback. Comments like your actually motivate me to continue :)

[@thewelder3538]

@@Codewrinkles You definitely ARE in need of education if you're actually under under the impression that using an exceptions rather than a result is a good idea. This isn't something I say, it's something I know and have learned in my nearly 40yrs of coding. It is a little language dependent sometimes, especially when an exception signature isn't intrinsicly part of the specific language you might be using, but it's nearly ALWAYS better to use a result rather than an exception. It's one of the main reasons exceptions are called "exceptions" because they're for handling exceptional circumstances and NOT general errors. Now I could write loads of specific proof as to why this is the case, but as I said, it's not my job to educate you. It's generally a very junior thing to do to use exceptions as some kind of error handling, but you come across like someone who's going to believe your nonsense until someone proves you wrong. And even then, you'll probably still think you're right.

[@henriquesouza5109]

I also think results is always better than exceptions, but I also noticed how hard it is to work with them depending on the language paradigm. That's all what he is saying on the video. And it is an important advice: don't force unsupported features from paradigms different than your language paradigm. Currently, in C#, it is a exception oriented language when it comes down to error handling. There are a few functional libraries but that's not an easy thing to use at business work. Imo error codes, boolean and string returns are C style error handling, not even close to the Result pattern in Rust, for example. Once Microsoft starts giving more support to the result pattern, then we might be able to use it even at work. Today, unfortunately, we rely on exceptions (tell me one library that gives you a result object instead of throwing an exception).

[@allannielsen4752]

@@henriquesouza5109 TypedResult used in aspnet mvc to return BadResult OR NotFound OR Ok. Why all this argument, it's not a one or the other scenario? The right tool for the job. You don't, can't pass exceptions across boundaries, you pass results. What you do inside your domain is entirely up to you as dictated by your requirements. But I don't want a 500 server error (normally caused by exceptions), I want more detailed response, that I as your client can act on.

[@AlbertoMonteiro]

@@henriquesouza5109 Refit does something like that, if you use an ApiResponse it doesn't throw an exception when you don't get a 2xx status code, but if you use Task then you will get it. But the exception should mean that you have a bug and most time, I've seen people using exceptions because exception can easily break the code flow. It would help if you had a stack trace when you have and bug, not when you are validating something... The Result pattern is not to avoid exception, it is to avoid misusing exceptions.

[@luciannaie]

I would argue that the runtime has the responsibility to handle exceptions fast to not incur major penalties to using the exceptions pattern. great talk!

[@Codewrinkles]

Many thanks for your toughtful contribution. Also thanks for watching. If you think it might be valuable, feel free to share it with colleagues or whoever you think might find this video insightful.