Re: Getting exception object
- you don't know what you catch, so you cannot recover from the error.
The latter does not follow from the former.
You don't know what caused your program execution to end up in the catch
handler.
Ergo, you don't know the state of your software. It could be corrupted, in
an invalid state, or simply telling you that you read past the end of a
file.
Ergo, you cannot know if it is safe to continue execution or not.
- pre V2005, catch(...) also catches structured exceptions (like access
violations etc) and silently munches it.> whatever you do then will lead
to undefined behavior.
What do you mean by "munches?"
to make disappear. I have seen catch(...) being triggered by an access
violation due to buffer overrun.
The handler would do whatever it was supposed to do, call throw; again, and
instead of rethrowing, execution
would continue after the handler as if nothing had happened.
This would leave you with a completely corrupted system that would keep
running for another n minutes, and then crash
while supposedly doing nothing exciting at all.
because of these 2 reasons, a design that relies on catch(...) is a bad
design.
And IMO it is a serious flaw within the C++ language itself to allow you
to throw anyhing that doesn't derive from 1 specific exception base.
You're entitled to your opinion.
Thanks.
Exceptions are supposed to be exceptional.
The performance overhead induced by throwing a true exception object instead
of e.g. an int should be no factor in design.
Having a common exception class enables you to use a generic set of helper
functions for dealing with exceptions, logging to disk , displaying,
extracting the meaning etc...
without a common base type you have to catch all specific types of
exceptions, and have lots of non generic non reusable code.
--
Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"