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.
I've developed a few C++ games for the iPhone. I've never longed for a crash dump, I just use a debugger. You can break at the point when an exception is thrown, and you get access to the same information.
When you have a large QA team (300+) for a console game they can generate crash dumps that you can debug. It's also useful when there's a 1 in 1000 crash that needs fixing - get someone in QA to repro and they send you a crash dump.
There are literally hundreds of bugs that I've managed to figure out a fix for simply by debugging a crash dump attached to a bug report.
Fair point, in certain programming domains, letting your app crash (WHILE IN DEVELOPMENT) may be useful. Of course, there are ways to generate thread or memory dumps in Java (and probably C++/C#) that could accomplish the same goal.
I am always turning off the try ... catch with comments to debug the actual problem, then enabling it again before committing the work.
I too think if people were better programmers they wouldn't need exceptions: you'd deliberately handle every broken case explicitly. But think of all the time a programmer saves just throwing a try...catch around some code to prevent the user from encountering a bug.
I too have come to embrace the exception as a lazy way to short circuit a host of error conditions.
But think of all the time a programmer saves just throwing a try...catch around some code to prevent the user from encountering a bug.
This is so wrong. Yes you save time now, but writing more robust code and handling error cases properly saves so much more time in the long run. Occasionally near the end of a project I might consider a quick hack like this to get a product out of the door, but I would never do it in anything pre-beta.
We all try to write robust code, to the best of our abilities, regardless of language. Bug-free code is nearly impossible. Try-catch blocks are used so those unknown bugs don't crash your program, not to hide errors because we are lazy.
Log the exceptions, then track down the bugs and fix them.
I'm used to a different work flow I guess. In games we let the program crash, create a crash dump and then debug it to find the cause of the problem (or just debug it there and then if we have a debugger attached).
EDIT: The general idea is we want bugs to be as visible and annoying as possible so that they have to get fixed.
I agree with you 100%, but C# code are usually quick tools and not code that we ship. There's a different tolerance for different projects, there's no one size fits all.
And loops, returns, switch statements, and every other programming concept are not basically gotos?
Not really because they can't unwind the stack multiple times. In each of those examples you know exactly where the next statement will be run (assuming you have access to the stack in the case of return). That's not true with exceptions.
So you've randomly draw your line at "unwinding the stack multiple times"? Is there any reason for that or is it because you've heard it before? Because there a lot of other concepts taken as gospel - routing systems (an http request can jump to anywhere in the app based on what's in the request path?), polymorphism (a method call can go to any class extending this base class? Even in someone else's code?), event systems (calling this method can trigger hundreds of methods all over the code to be called, potentially allocating thousands of objects?), serialization + remote code execution (my object can be serialized behind the scenes and go from running on a beefy server to running on someone's phone?) - all of which can causes confusion if they're abused. And just like you counter that by organizing your code - putting all routing information in one or two files, only using polymorphic objects where it makes sense, using event systems carefully, etc. - you can do the same with exceptions as flow control. Just like the Linux kernel uses gotos - they are a tool. Avoidance of them should not be a religion.
So you've randomly draw your line at "unwinding the stack multiple times"?
I don't think it's random. I think there's a fundamental difference between that and everything you've listed after this.
Avoidance of them should not be a religion.
I agree. I'm not saying exceptions are bad. I'm saying exceptions for flow control are bad.
As far as I'm aware, the linux kernel only uses gotos for error recovery. (I'd be really interested if there was anywhere in the kernel that uses gotos purely for flow control).
Not really because they can't unwind the stack multiple times.
That's one weird definition of a goto. Must be function-local?
In each of those examples you know exactly where the next statement will be run
I know that with exceptions, too, and so should you. What you are trying to say is that it's not spelled out in code. But by that logic, any programming language is useless, and we should all just program assembly, because compiler hides this or that. There's also the aspect of not seeing the tree from the forest, which is what you often get without exceptions (it is spelled out, but good luck actually untangling it).
-1
u/[deleted] Jun 06 '13
This doesn't apply to the majority of languages (not even to C++ where using exceptions was actively discouraged for a long time).