cowlick

Do you use it? In what type of applications? Is it ever acceptable to mix EH and non EH code?

__________________
"It's a long story," says I, and let him up.

cheerios

don't use it, but don't code often in C++ DID find a neat trick thought....
catch(...){

}

is valid, WITH the ...'s. it's a catch-all. laughed my ass off reading that in an intro to C++ book

Quadraton

That should actually be a standard practice when using exception handling. It saves your program from 'crashing' with an unhandled exception (an exception that isn't 'caught' before the program exits). And even if you aren't using exception handing, there's nothing saying that someone else using your C++ code won't use it later on, so it's always a good idea to put the catch( ... ) around the main loop.

i.e.
Another neat trick you can do with exception handing is something like:

So, in a sense, you 'rethrow' the exception so that it can be caught higher up in the code. And if there are no catch's higher up, then the catch( ... ) will get it.

__________________
"A witty saying proves nothing"
- Voltaire

cowlick

Whoa!
catch(...)
is one of the worst things to write. Think of it this way. You're writing a device driver. You've got a catch(...) to handle everything. In the device driver, you somehow manage to access memory you shouldn't. Maybe you buffer overwrite, maybe you overread due to a bad format string, who knows? Now the catch(...) catches the AV. How the hell have you helped anyone? They should have AV'd but instead you keep running even though the driver is completely shot and unlikely to work properly from here on in.

__________________
"It's a long story," says I, and let him up.

Quadraton

That's a good point, but my opinion is that letting an unhandled exception fall through serves no purpose whatsoever. The system doesn't tell you where that unhandled expection occured, either in the error box (Windows), or the core dump (UNIX/Linux), or that it was even an unhandled exception that caused the program to crash in the first place. If anything, you can always just do the following:

or write the error to a log file, or to sterr, or whatever.

In the end, I guess it's up to the developer to make the decision, but experience has taught me that unhandled exceptions that fall through can be a headache to debug. And ideally, a well written piece of code should have a catch() for all thrown exceptions, but this method handles the 'just in case".

__________________
"A witty saying proves nothing"
- Voltaire