5 ms·

It could actually. Exceptions and RAII are not resilient against typos and programmer error. If the exception handler caught the wrong type, for example catchi

It could actually. Exceptions and RAII are not resilient against typos and programmer error. If the exception handler caught the wrong type, for example catching by value instead of reference, instead of having a catch(...) it would have the same problem as the above. It's harder to spot this sort of error than a double goto and incorrect parentheses - because you have to check the code that throws and the code that catches. Admittedly in the scenario I lay out - what happens is an error is thrown and not caught, rather than a check being skipped, but the net effect is equivalent - and it takes 1 character out of place to invoke.

nikbackm 13y ago
I don't see the possibility for catching the wrong type (or not catching it) if you get one character wrong. Unless of course you have two valid type names that just differ in one character, but that is a general pitfall and not exception specific. If you always throw by value (and not by pointer) then it does not matter if you catch by value or by reference, the catch block will be activated either way. The only issue is possible slicing if you throw a derived instance and catch a base class type. You might lose error information that way, but the program will not crash due to an uncaught exception.
- eliasmacpherson 13y ago
  Ok for example: int e; int update() { throw &e; } the & is the one character - it's a typo - only catch(...) will catch it.
  - nikbackm 13y ago
    Well, since you're throwing an int-pointer then catch(int*) should also catch it quite happily. I guess you mean there will only be a catch(int) in addition to catch(...) so in that aspect you're right of course. Still, I would think taking the address of something you throw should ring quite a few warning bells as opposed to merely a missing ref (&) in the catch handler. Similarly to "return &e" which would also be suspicious and require an extra look or two.
    - eliasmacpherson 13y ago
      My point being it would raise far less warning bells than an unguarded goto.

nikbackm 13y ago

I don't see the possibility for catching the wrong type (or not catching it) if you get one character wrong. Unless of course you have two valid type names that just differ in one character, but that is a general pitfall and not exception specific. If you always throw by value (and not by pointer) then it does not matter if you catch by value or by reference, the catch block will be activated either way. The only issue is possible slicing if you throw a derived instance and catch a base class type. You might lose error information that way, but the program will not crash due to an uncaught exception.

eliasmacpherson 13y ago
Ok for example: int e; int update() { throw &e; } the & is the one character - it's a typo - only catch(...) will catch it.
- nikbackm 13y ago
  Well, since you're throwing an int-pointer then catch(int*) should also catch it quite happily. I guess you mean there will only be a catch(int) in addition to catch(...) so in that aspect you're right of course. Still, I would think taking the address of something you throw should ring quite a few warning bells as opposed to merely a missing ref (&) in the catch handler. Similarly to "return &e" which would also be suspicious and require an extra look or two.
  - eliasmacpherson 13y ago
    My point being it would raise far less warning bells than an unguarded goto.