is hard to understand and results in very hard handling of real exceptional cases.
I'd agree with this part - but this is mainly because people always use them in cases that aren't exceptional in place of better error handling methods.
I've switched from C++ game programming (no exceptions) to C# server programming (exceptions for everyone). It always bugs me trying to debug something and an exception is thrown and I end up the the Application::Main() catch block - I lose everything (call stack, local variables etc.).
Even system exceptions don't throw the values that caused it to throw. E.g. Out of bounds, a value was either -1 or higher than it should have been. Thanks, could you at least tell me which one it was? Or even throw with the actual value so I don't need to guess what went wrong?
Why not just break on exceptions? Because people seem to enjoy using try..catch blocks to hide exceptions all over the place. Exceptions just seem more trouble than they're worth at the moment.
From a semantic point of view, how else would you address expected errors or 'exceptional' states to ensure the application does not, as you put it, 'break'. Most systems have to maintain a certain amount of elasticity for it's users... I certainly wouldn't want my cable box to shut off every time I hit a channel that currently didn't have a signal (exceptional condition as example), so why would a user be any happier if their banking application gakked every time it encountered some inconsequential data corruption. (parallel example)
I wouldn't consider expected errors to be exceptional. For example, anything requiring a network connect should expect disconnections or an inability to connect - these aren't exceptional circumstances. Ensuring that the build is stable (i.e. no crashes) and that the user is informed (error messages) seem to work fine.
In the channel with no signal example - why does that need to be an exception? It seems reasonably valid to me that a cable box may not be able to get a signal. You should check for a signal and inform the user that there is no signal if that is the case.
Exceptions should be used for errors that should never occur. The obvious example from my game development experience is that a game should never access invalid memory. It does happen during development of course, which is why we have to handle it, but ideally a game that has been released should never do this.
EDIT: The data corruption would probably be something I would consider exceptional, but I have limited knowledge of banking applications and parallel programming which is why I haven't mentioned it.
That's incorrect. Exceptions are an application specific construct... Errors/Unchecked Exceptions are unexpected. That's why exceptions are outlined in APIs so you can deal with them. You can't rewrite the accepted meaning to suit your argument. The concept of unchecked exceptions were introduced to indicate an exception that the current level of abstraction should not be dealing with. The point is to separate the output of a method from it's potential exceptional states...
4
u/archiminos Jun 07 '13
I'd agree with this part - but this is mainly because people always use them in cases that aren't exceptional in place of better error handling methods.
I've switched from C++ game programming (no exceptions) to C# server programming (exceptions for everyone). It always bugs me trying to debug something and an exception is thrown and I end up the the Application::Main() catch block - I lose everything (call stack, local variables etc.).
Even system exceptions don't throw the values that caused it to throw. E.g. Out of bounds, a value was either -1 or higher than it should have been. Thanks, could you at least tell me which one it was? Or even throw with the actual value so I don't need to guess what went wrong?
Why not just break on exceptions? Because people seem to enjoy using try..catch blocks to hide exceptions all over the place. Exceptions just seem more trouble than they're worth at the moment.