4 ms·

Exceptions are great when you want errors to terminate a (sub)program with an error message without having to type any code at all. That's suitable for batch p

Exceptions are great when you want errors to terminate a (sub)program with an error message without having to type any code at all. That's suitable for batch programs and other short running things where you can just scrap the incomplete computation and re-try with a blank slate. I'm sure that can be productive for webapp code that sits between a database and the frontend. For longer running processes and more complex systems, exceptions are not so great. It's almost a given that you will have a hard time tracking down all the error scenarios in your system.

vips7L 6y ago
> For longer running processes and more complex systems, exceptions are not so great. It's almost a given that you will have a hard time tracking down all the error scenarios in your system. I disagree. I absolutely love throwing exceptions from lower levels of my web apps and letting them bubble to be handled by exception mappers that will formulate the correct http response from them.
- ufo 6y ago
  I think the parent poster would classify that kind of web app under as a "short running thing". Sure, the application process might live for a long time but the requests are short-lived and independent of each other.
  - TeMPOraL 6y ago
    Every program is a collection of a lot of "short running things". Exceptions work well with this. There's a piece of code that calls some function and expects a result or an error; there's a piece of code much deeper in the stack that can fail. Everything in the middle doesn't care about the failure, except to make sure it doesn't get executed if the failure occurs. Without exception-like mechanism, you have to make the middle care about possible errors, just to prevent code past failure point from executing. Your calls like foo(a) get turned into if(a != error) { foo(a); }, even if it's hidden behind a nice monadic syntax.
- chubot 6y ago
  parent: I'm sure that can be productive for webapp code that sits between a database and the frontend.
wvenable 6y ago
The last desktop app I wrote had a single error handler at the event loop that displayed an error message and continued. Because the stack unwinding cleanup is the same when an exception occurs or when an operation completes normally this app could recover from anything. > It's almost a given that you will have a hard time tracking down all the error scenarios in your system. You don't need to track down all the error scenarios. The only thing you need to worry about is things that you can recover from to retry and things you can't. Passing errors around places too much emphasis on where errors occur. For recovery you only need to know what you can recover from and where you can do that recovery. This is usually no where near where the error occurs.
- jstimpfle 6y ago
  > Passing errors around places too much emphasis on where errors occur. For recovery you only need to know what you can recover from and where you can do that recovery. This is usually no where near where the error occurs. This is actually the best argument why exceptions do not "scale": Because in larger systems, the place where you handle the error is almost certainly not up the call stack, but in a different subsystem. > Passing errors around places too much emphasis on where errors occur. For recovery you only need to know what you can recover from and where you can do that recovery. This is usually no where near where the error occurs. In a way, errors are just data, like everything else. There is not much sense in making them something special - as I said, with the exception of smaller script-like programs, where you usually want to jump out of a larger subprogram immediately, and rely on the garbage collector / stack unwinding to clean up (hopefully, everything) for you.
  - wvenable 6y ago
    > There is not much sense in making them something special The reason you treat them as special is because at the point an error/exception occurs you are saying that your function (or program) can no longer do any more meaningful work, forward progress is now impossible, and you can't return anything meaningful. We've gone backwards in making error returns explicit because the most common and intelligent thing to do is pass the error back up the chain or right out of the subsystem entirely. The lazy approach is the correct one with exceptions. > Because in larger systems, the place where you handle the error is almost certainly not up the call stack, but in a different subsystem. If your subsystem is network connected then the most likely cause of an re-startable operation is a minor network issue. There's no need to inform another subsystem immediately. I don't really see how it's an argument that exceptions don't scale. If you need to inform another subsystem you can do that.

vips7L 6y ago

> For longer running processes and more complex systems, exceptions are not so great. It's almost a given that you will have a hard time tracking down all the error scenarios in your system. I disagree. I absolutely love throwing exceptions from lower levels of my web apps and letting them bubble to be handled by exception mappers that will formulate the correct http response from them.

ufo 6y ago
I think the parent poster would classify that kind of web app under as a "short running thing". Sure, the application process might live for a long time but the requests are short-lived and independent of each other.
- TeMPOraL 6y ago
  Every program is a collection of a lot of "short running things". Exceptions work well with this. There's a piece of code that calls some function and expects a result or an error; there's a piece of code much deeper in the stack that can fail. Everything in the middle doesn't care about the failure, except to make sure it doesn't get executed if the failure occurs. Without exception-like mechanism, you have to make the middle care about possible errors, just to prevent code past failure point from executing. Your calls like foo(a) get turned into if(a != error) { foo(a); }, even if it's hidden behind a nice monadic syntax.
chubot 6y ago
parent: I'm sure that can be productive for webapp code that sits between a database and the frontend.

wvenable 6y ago

The last desktop app I wrote had a single error handler at the event loop that displayed an error message and continued. Because the stack unwinding cleanup is the same when an exception occurs or when an operation completes normally this app could recover from anything. > It's almost a given that you will have a hard time tracking down all the error scenarios in your system. You don't need to track down all the error scenarios. The only thing you need to worry about is things that you can recover from to retry and things you can't. Passing errors around places too much emphasis on where errors occur. For recovery you only need to know what you can recover from and where you can do that recovery. This is usually no where near where the error occurs.

jstimpfle 6y ago
> Passing errors around places too much emphasis on where errors occur. For recovery you only need to know what you can recover from and where you can do that recovery. This is usually no where near where the error occurs. This is actually the best argument why exceptions do not "scale": Because in larger systems, the place where you handle the error is almost certainly not up the call stack, but in a different subsystem. > Passing errors around places too much emphasis on where errors occur. For recovery you only need to know what you can recover from and where you can do that recovery. This is usually no where near where the error occurs. In a way, errors are just data, like everything else. There is not much sense in making them something special - as I said, with the exception of smaller script-like programs, where you usually want to jump out of a larger subprogram immediately, and rely on the garbage collector / stack unwinding to clean up (hopefully, everything) for you.
- wvenable 6y ago
  > There is not much sense in making them something special The reason you treat them as special is because at the point an error/exception occurs you are saying that your function (or program) can no longer do any more meaningful work, forward progress is now impossible, and you can't return anything meaningful. We've gone backwards in making error returns explicit because the most common and intelligent thing to do is pass the error back up the chain or right out of the subsystem entirely. The lazy approach is the correct one with exceptions. > Because in larger systems, the place where you handle the error is almost certainly not up the call stack, but in a different subsystem. If your subsystem is network connected then the most likely cause of an re-startable operation is a minor network issue. There's no need to inform another subsystem immediately. I don't really see how it's an argument that exceptions don't scale. If you need to inform another subsystem you can do that.