I’m just a hobbyist but…are you guys using exceptions like they’re conditional statements?? I thought those were for only when shit is seriously wrong and execution can’t continue in the current state. Like if some resource was in a bad state or some input was malformed.
Or maybe I haven’t worked on anything complex enough, I dunno.
As a rule, exceptions should indeed be used for behaviors that are outside normal execution flow. For example, you might throw an exception if a file you’re trying to access doesn’t exist, or a network call fails, etc.
I suppose it depends on the language? For the most part I think you’re right. Exceptions are only used (if at all) in situations where a program diverges unexpectedly from its normal flow. But take a language like Python. They’re just everywhere. Even your plain old for loop ends on an exception, and that’s just business as usual.
Python programmers appear to actively promote the ‘easier to ask forgiveness, than permission’ style nowadays. This article has a measured take: https://realpython.com/python-lbyl-vs-eafp/
You don’t want to use exceptions in normal control flow, because they’re extremely slow. Every time you throw an exception, it has to collect a stacktrace, which is hundreds, if not thousands, of calculations, compared to a handful of calculations for returning a boolean or an enum variant.
You can set up a global exception handler in some frameworks. By having multiple (not a crazy amount) of exceptions, you can set up logic for how to handle that kind of error. Then you can just throw the exception instead of writing individual catch blocks.
This is especially helpful in things like a REST API where user input can cause all kinds of fun, let alone network issues, problems with your data source, etc.
I’m just a hobbyist but…are you guys using exceptions like they’re conditional statements?? I thought those were for only when shit is seriously wrong and execution can’t continue in the current state. Like if some resource was in a bad state or some input was malformed.
Or maybe I haven’t worked on anything complex enough, I dunno.
That’s how it starts. Nice and simple. Everyone understands.
Until
and you decide you want to recover from that situation, but you don’t want to refactor all your code.
Suddenly, catching exceptions and rerunning seems like a good idea. With that normalized, you wonder what else you can recover from.
Then you head down the rabbit hole of recovering from different things at different times with different types of exception.
Then it turns into confusing flow control.
The whole Result<ReturnValue,Error> thing from Rust is a nice alternative.
As a rule, exceptions should indeed be used for behaviors that are outside normal execution flow. For example, you might throw an exception if a file you’re trying to access doesn’t exist, or a network call fails, etc.
I suppose it depends on the language? For the most part I think you’re right. Exceptions are only used (if at all) in situations where a program diverges unexpectedly from its normal flow. But take a language like Python. They’re just everywhere. Even your plain old
forloop ends on an exception, and that’s just business as usual.Python programmers appear to actively promote the ‘easier to ask forgiveness, than permission’ style nowadays. This article has a measured take: https://realpython.com/python-lbyl-vs-eafp/
You don’t want to use exceptions in normal control flow, because they’re extremely slow. Every time you
throwan exception, it has to collect a stacktrace, which is hundreds, if not thousands, of calculations, compared to a handful of calculations for returning a boolean or an enum variant.You can set up a global exception handler in some frameworks. By having multiple (not a crazy amount) of exceptions, you can set up logic for how to handle that kind of error. Then you can just throw the exception instead of writing individual catch blocks.
This is especially helpful in things like a REST API where user input can cause all kinds of fun, let alone network issues, problems with your data source, etc.