4 ms·

I agree with you, but it's important to acknowledge the strength of the argument against exceptions. I think Raymond Chen put forth some of the best arguments,

I agree with you, but it's important to acknowledge the strength of the argument against exceptions. I think Raymond Chen put forth some of the best arguments, claiming they were human error prone: https://blogs.msdn.microsoft.com/oldnewthing/20050114-00/?p=36693 https://blogs.msdn.microsoft.com/oldnewthing/20050114-00/?p=... https://blogs.msdn.microsoft.com/oldnewthing/20040422-00/?p=39683/ https://blogs.msdn.microsoft.com/oldnewthing/20040422-00/?p=... While forceful, I don't accept the conclusion of Raymond's argument. I feel it may be true for programmers primarily trained and experienced in C, but is not true in general. As such, the argument reduces to "programmers who are not familiar with exceptions sometimes make mistakes when using them." One could say the same thing about pointers, dynamic typing, lambdas, macros, comprehensions, pass-by-reference, etc. Today, most programmers are familiar and comfortable with exceptions, having almost certainly been taught to use them in college and almost certainly using them on a daily basis for their entire professional career. They'll also have been taught to use a language-specific toolbox such as RAII or try/catch/finally to deal with any potential problems. Once you get in the habit, it's not hard to scan through a program line-by-line asking yourself "what would happen if an exception were thrown at this point?" and to take appropriate precautions. In fact, I'd wager that for anyone who's spent years working in any language with exceptions this quickly becomes second nature. It's also an easy way to add value during peer code review. In my experience, writing correct code with exceptions is not "really hard," as Raymond argues, but rather no harder and a lot quicker that using explicit error handling. The reason it's a lot quicker is because "exit the function with an error status and do local cleanup of variables initialized so far" is by far the most common correct action. And for cases when its not, the try/catch/finally or other exception handling whatever is straight forward to write and no uglier than explicit error handling would have been. Of course, it's possible I think this because I've worked in languages with exceptions for most of my career. But I certainly don't observe that even the most junior programmers on my team create a ton of bugs that could be attributed to mishandled exceptions. In fact, I can only remember a handful of such bugs, mostly involving open database transactions or unhelpful error messages masking more detailed error messages. A more solid objection to language support for exceptions can be made by pointing out all invisible code generated by the compiler to correctly handle exceptions. This can lead to significant code bloat and in some cases can negatively impact performance. Or by pointing out how unwise it is to be allocating additional Exception objects while dealing with out of memory errors. These are some of the reasons why C++ isn't appropriate for an OS kernel, for example.

jstimpfle 8y ago
> Once you get in the habit, it's not hard to scan through a program line-by-line asking yourself "what would happen if an exception were thrown at this point?" and to take appropriate precautions. I feel there's a serious disagreement here with how I tend to look at things. I don't want to look line-by-line and ask what would happen in case of an exception. In most cases the answer would be: That would be bad, since the rest of the code would not get executed and the program would remain in an invalid state. It's much easier to know that there will not be an exception. Simple sequential code, the way it was intended to be by the ancient gods. And handle errors manually where they could in fact occur. I reckon that for my own code, that is only once in a hundred lines or more. Or maybe even more (lines) than that, since I'll abort directly in the callee in many cases anyway, so the caller never gets a chance to see the error. But if there were any point in handling an error in the future, we can still switch to handling it later. Now you can argue that you can do that with exceptions as well (handling errors directly either by returning an error code or by aborting) such that exceptions would never bubble up. But in that case what's the point in exception handling to begin with? It's just the same now, except that there's a lot of exceptions machinery required in the language.
- renox 8y ago
  Is there such thing as 'simple sequential code'? Simple? Additions may overflow, printf may fail, etc. Usually code looks simple only because it ignores errors.. As for sequential, we're in the age of multiple cores and GPUs..
  - jstimpfle 8y ago
    Of course, sequential code is simple. Overflowing additions don't have anything todo with the code. They overflow or not. > Usually code looks simple only because it ignores errors.. No, it looks simple when the structure is right. There are other error handling strategies than "handle it now, or pop the stack frame and let your caller handle it now!". But with exceptions that's all the choice you are given (unless you convert them to regular data). Since exceptions strongly discourage alternative error handling schemes, no wonder they lead to unmaintainable code as soon as a considerable amount of conditions actually should be handled, instead of just bailing out. > As for sequential, we're in the age of multiple cores and GPUs.. What point are you trying to make? Obviously what I mean by sequential code here is that you can easily reason "if control flow reaches point A, then B will be executed, too".

jstimpfle 8y ago

> Once you get in the habit, it's not hard to scan through a program line-by-line asking yourself "what would happen if an exception were thrown at this point?" and to take appropriate precautions. I feel there's a serious disagreement here with how I tend to look at things. I don't want to look line-by-line and ask what would happen in case of an exception. In most cases the answer would be: That would be bad, since the rest of the code would not get executed and the program would remain in an invalid state. It's much easier to know that there will not be an exception. Simple sequential code, the way it was intended to be by the ancient gods. And handle errors manually where they could in fact occur. I reckon that for my own code, that is only once in a hundred lines or more. Or maybe even more (lines) than that, since I'll abort directly in the callee in many cases anyway, so the caller never gets a chance to see the error. But if there were any point in handling an error in the future, we can still switch to handling it later. Now you can argue that you can do that with exceptions as well (handling errors directly either by returning an error code or by aborting) such that exceptions would never bubble up. But in that case what's the point in exception handling to begin with? It's just the same now, except that there's a lot of exceptions machinery required in the language.

renox 8y ago
Is there such thing as 'simple sequential code'? Simple? Additions may overflow, printf may fail, etc. Usually code looks simple only because it ignores errors.. As for sequential, we're in the age of multiple cores and GPUs..
- jstimpfle 8y ago
  Of course, sequential code is simple. Overflowing additions don't have anything todo with the code. They overflow or not. > Usually code looks simple only because it ignores errors.. No, it looks simple when the structure is right. There are other error handling strategies than "handle it now, or pop the stack frame and let your caller handle it now!". But with exceptions that's all the choice you are given (unless you convert them to regular data). Since exceptions strongly discourage alternative error handling schemes, no wonder they lead to unmaintainable code as soon as a considerable amount of conditions actually should be handled, instead of just bailing out. > As for sequential, we're in the age of multiple cores and GPUs.. What point are you trying to make? Obviously what I mean by sequential code here is that you can easily reason "if control flow reaches point A, then B will be executed, too".