gast128
Hello David,
my point is that exceptions are fatal when not dealt with. This can be a good thing in case of fatal exceptions (e.g. memory exhaustion),
Whether or not memory exhaustion should be fatal to a program is open to debate, but if you do need to shut the program down completely and quickly, exceptions are usually not the right mechanism to do it (http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/800...)
but bad when the exceptions are not that severe (e.g. string length on a NULL string).
If that's a programming bug, it should almost certainly *not* throw an exception.
Another item is that I think that one of the rationales is that it is cleaner to write code like:
void Foo() { try { //write logic } catch () { //write exception case(s) } }
Rationales, for what? Cleaner than what?
This throwing ctor stuff can be annoying if one considers the follwing case:
void GetAllEmployees() { std::vector<Employee> v;
Employee e = Load(...) v.push_back(e);
//etc. }
consider that one of the employees can 'become' corrupt.
It's almost impossible to write reasonable programs when you have to "consider that one of the xxx objects can 'become' corrupt." http://groups.google.com/group/comp.lang.c++.moderated/msg/659b9db50f587dab
But still the rest of the employees should be dealt with. With exception handling it becomes:
void GetAllEmployees() { std::vector<Employee> v;
try { Employee e = Load(...) v.push_back(e); } catch () { }
//etc. }
No more nice seperation between logic and exception.
I don't know why anyone would do that. Which employee has 'become' corrupt here, and how does the above code supposedly help? It seems to just eat exceptions and mask errors, nothing more. -- Dave Abrahams Boost Consulting www.boost-consulting.com