The code that catches an exception can continue, but the point was about the code that threw the exception. You throw an exception if you can't continue the work you're currently doing, for whatever reason. Of course, the rest of the program can very well continue: some other part will catch the exception you threw and decide what to do next. Ending the entire process is an extreme case, that should be reserved for only global problems - out of heap space errors, memory corruption, security violations, deadlock detection. Anything else should result in a more localized failure - killing a thread, a task, a request processor etc.
Also, there is little fundamentally different between throwing an exception and returning an error result. Everything I wrote above applies just as much to error results as it does to exceptions. Exceptions are just a language-level mechanism to help with a common error pattern: the code that detects an error condition is typically very far away from the code that can handle that error condition. When an error happens, the vast majority of the time, what happens next is that the error will be cascaded back through the call chain to a handler function of some kind. Along the way, some context will be added to the error, and some resources will be cleaned up. You can do this by hand, as you would in Go or Rust, or you can have the runtime do it for you, like in Java or C#. There are pros and cons to both (implicit vs explicit, how relevant is the context, etc), but fundamentally the program will take the exact same path.
> Also, there is little fundamentally different between throwing an exception and returning an error result.
Thank you. I was about to reply the same. The most notable difference is that from a usage-perspective is that exceptions bubble up automatically, whereas errors must be returned manually.
I usually don't follow the error vs. exception debate because both have their difficulties and both let's you write code that behaves different than you anticipate.
I prefer exceptions, especially how Python handles them (most of them at least). The only thing I really would love to see is something like Rusts Option() type in Python so assigning values to variables inside a try: would not require me to have variables with typ int|None. That's really yuck.
Also, there is little fundamentally different between throwing an exception and returning an error result. Everything I wrote above applies just as much to error results as it does to exceptions. Exceptions are just a language-level mechanism to help with a common error pattern: the code that detects an error condition is typically very far away from the code that can handle that error condition. When an error happens, the vast majority of the time, what happens next is that the error will be cascaded back through the call chain to a handler function of some kind. Along the way, some context will be added to the error, and some resources will be cleaned up. You can do this by hand, as you would in Go or Rust, or you can have the runtime do it for you, like in Java or C#. There are pros and cons to both (implicit vs explicit, how relevant is the context, etc), but fundamentally the program will take the exact same path.