On tor, 2007-08-23 at 22:24 +0900, Jon Keating wrote: > Sorry for the late reply, have been fairly busy as of late. > > I'm going to have to _strongly_ disagree with the tide of this discussion. > > On Wednesday 22 August 2007 03:25, Anders Olofsson wrote: > > Didn't know about that one but after some googling I must say that > > std::unexpected sounds perfect to use. If we are just gonna catch the > > critical exceptions in one place anyway it must be better to use it > > instead of adding it to throw clause on all functions which will also > > allow any non-critical exceptions which we might not want to allow > > everywhere. > > Yes, it sounds perfect, but when you try it out you will see that it is more > of a deterrent than anything else. std::unexpected does not return a value, > which means that there are only 2 things it can do: > > 1) Rethrow an exception that just happens to be in the specifier of the > original function. > > 2) Terminate the program. > > #1 relies on luck, and #2 is not much of a solution either. > > > Yes, if you're gonna have that kind of error handling for every call, > > we'll have 10 times the size of the code just for all those catch > > blocks. Better to have it in one place and make that as good handling as > > possible. > > Why have it only one place? Why not have it in the appropriate places: The > boundaries of the daemon. Even without an exception specification, the > document should provide the details of what exceptions to expect. Other > exceptions, should indicate a fatal error condition. i.e., no memory left, > corrupted memory, etc.
I ment std::unexpected only to handle the fatal stuff, like memory shortage or cast problems. If one of these happens I don't think we have much possibilty to do a good recovery, the best we can do is (try) to terminate in a controlled way. For any other less than fatal exceptions, then of course they should be handled in appropriate locations. If do not use std::unexpected, then to handle the fatal exceptions any function with a throw clause must allow std::exception which also allows all exceptions makeing the throw clause useless as the purpose of it AFAIK is to limit which exceptions the caller must handle. I was refering mostly to the exception class which checked for out of memory exception from the exception base class constructor. If the std::exception class couldn't allocate memory, what are the chances we can continue running and do anything useful, better to terminate before we do something really bad and as I see it there is no point to have such crash-termination in more than one place and std::unexpected looks like the place. Anyway if std::exceptions hasn't got enough memory to create itself, where did we get the memory from to allow it to create another exception and then throw it? =) /Anders
