a question of style when catching exceptions
in [C++]
|
Prev: Loki::Function
Next: Right Endian conversion
From: Nick Maclaren on 12 Aug 2010 03:17 In article <ebe14884-112b-4a4b-9548-af75142624fd(a)p7g2000yqa.googlegroups.com>, Kenneth 'Bessarion' Boyd <zaimoni(a)zaimoni.com> wrote: >On Aug 7, 5:18 am, Nick Hounsome <nick.houns...(a)gmail.com> wrote: > >> IMHO it would probably be better if there had been something like >> java's Throwable at the bottom of the hierarchy where you could put >> stuff like bad_alloc which you really don't want to catch under any >> circumstances. > >Well, any circumstances other than maintaining 100% uptime. That's not a plausible target either for portable C++ or under any current mainstream operating system. It doesn't impact embedded programming, because one of the (many) rules for code aimed at that target would be to not use such exceptions! >std::bad_alloc is the only standard exception that is obviously >*reliably* recoverable from. At least, when the target platform's >memory manager is honest and the problem domain is loosely coupled >enough (this describes my usual problem domains). So it's the one I >normally think about catching. [Of course, always verify that NULL >return isn't a better option than throwing std::bad_alloc during the >first implementation pass.] Grrk. No, sorry. Firstly, not all failures to allocate storage are recoverable from at the operating system level. More importantly, it requires all components between the throw and the catch to be written to recover from it, no matter in WHAT construct the failure arose. Few are written like that, even when they attempt to, and I doubt that the standard library is required to be safe against bad_alloc under all circumstances. I agree that it's relatively reliable. The only major class that SHOULD be easier to recover from is numeric exceptions, but the history of utter incompetence in that area over most of the history of computing beggars description. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrew on 12 Aug 2010 03:12 On 6 Aug, 23:32, Mathias Gaunard <loufo...(a)gmail.com> wrote: > On Aug 5, 8:54 pm, Andrew <marlow.and...(a)googlemail.com> wrote: > > > 2) it throws std::logic_error because it has detected a situation that > > could only arise as a result of a coding error. > > I would suggest using an assert instead. No. We can't do that. The C assert macro is a no-op in production. This means that production code would core dump. We can't have it do that. These libraries we are forced to use are byzantine. They will fail due to coding errors. We who call them are supposed to carry on running when those routines fail due to coding errors. It's a crazy world.... > > 3) Access violation. Microsoft structured exception handling (SEH) > > turns these into C++ exceptions > > I believe this is disabled by default in recent versions of MSVC, and > should be kept disabled. It is disabled by default. It is enabled in the env in which I am working because otherwise the byzantine libraries would cause us to core dump. I don't like this any more than you do. My concern is not that the byzantine libraries contain coding errors. That's just not going to change. Neither is my concern that these errors would normally cause a core dump which is only avoided via SEH. This too is horibble but will remain for the foreseeable. My concern is that with the situation as it is, coding errors might be being swallowed so we don't even know it is going down these code paths. If the catch clauses always said catch (std::runtime_error&) rather than catch (std::exception&) then at least the coding errors would bubble up to a higher point where it is more appropriate to catch them. I just wanted to know what other people thought of this. My concern is that this strategy won't work if people inherit directly from std::exception rather than std::runtime_error. Regards, Andrew Marlow -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Kenneth 'Bessarion' Boyd on 12 Aug 2010 15:51 On Aug 12, 1:17 pm, n...(a)gosset.csi.cam.ac.uk (Nick Maclaren) wrote: > In article <ebe14884-112b-4a4b-9548-af7514262...(a)p7g2000yqa.googlegroups.com>, > Kenneth 'Bessarion' Boyd <zaim...(a)zaimoni.com> wrote: > > >On Aug 7, 5:18 am, Nick Hounsome <nick.houns...(a)gmail.com> wrote: > > >> IMHO it would probably be better if there had been something like > >> java's Throwable at the bottom of the hierarchy where you could put > >> stuff like bad_alloc which you really don't want to catch under any > >> circumstances. > > >Well, any circumstances other than maintaining 100% uptime. > > That's not a plausible target either for portable C++ or under any > current mainstream operating system. Ahem...what about portable FORTRAN? [Assume your choice of non- mainstream operating system.] > .... > > >std::bad_alloc is the only standard exception that is obviously > >*reliably* recoverable from. At least, when the target platform's > >memory manager is honest and the problem domain is loosely coupled > >enough (this describes my usual problem domains). So it's the one I > >normally think about catching. [Of course, always verify that NULL > >return isn't a better option than throwing std::bad_alloc during the > >first implementation pass.] > > Grrk. No, sorry. Firstly, not all failures to allocate storage are > recoverable from at the operating system level. So some operating systems make it impossible to implement honest memory managers. [Note: on Windows, failures of VirtualAlloc and related functions are empirically no-ops at the operating system level so *very* recoverable.] > More importantly, > it requires all components between the throw and the catch to be > written to recover from it, no matter in WHAT construct the failure > arose. This is practical in my usual problem domains. I just have, to enable this: * to avoid all but the most basic standard library templates * avoid array allocation of any type with a potentially throwing constructor, due to *all* major implementations explicitly violating the C++ standards. ** (tacit assumption: potentially throwing destructors are so buggy they will not be tolerated in the code base.) > .... > > I agree that it's relatively reliable. The only major class that > SHOULD be easier to recover from is numeric exceptions, but the > history of utter incompetence in that area over most of the history > of computing beggars description. Especially after said incompetence was explicitly standardized in IEEE 754 and its relatives. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nick Maclaren on 13 Aug 2010 03:38
In article <5ceb2acc-b7eb-4fca-801d-1363e892b6d3(a)i13g2000yqd.googlegroups.com>, Kenneth 'Bessarion' Boyd <zaimoni(a)zaimoni.com> wrote: >> >> >> IMHO it would probably be better if there had been something like >> >> java's Throwable at the bottom of the hierarchy where you could put >> >> stuff like bad_alloc which you really don't want to catch under any >> >> circumstances. >> >> >Well, any circumstances other than maintaining 100% uptime. >> >> That's not a plausible target either for portable C++ or under any >> current mainstream operating system. > >Ahem...what about portable FORTRAN? [Assume your choice of non- >mainstream operating system.] Not there, either. Fortran has no exception-handling facilities of any sort, though it does handle some classes of error better (and some worse). Once you get away from portability and mainstream operating systems, you can do more - probably in C++ as well. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |