Exception alternatives
in [C++]
|
Prev: CRTP question
Next: BinaryPredicate Question
From: sanelz on 26 Dec 2006 15:26 Greetings to all, I would like to ask, or hear some thoughts, if possible, about exceptions alternatives; I know this is very well discussed topic (with unclear solutions at the end ;-)), but my search through groups archives didn't yield any usefull solution, nor unfortunately, may popular books sais anything about this in the details. The main reason I am writing this is because today's "modern view" for library design looks like every possible error case should/must throw some kind of exception. I freely deducing last case after review of few recently downloaded libraries (without naming them, please), so cases like: try { File f("foo.txt"); // ... } catch(FileError& e) { // report, foo.txt can't be opened } becomes very common. Please, I don't want to start debate about exception (ab)using, but more like to get ideas with this topic in mind, where error handling should be possible for cases like: - open foo.txt - can't open it, try with baz.txt too. Of course, the only valid solution (in case of above libraries design) is to wrap it in try/catch blocks, but that becomes very inefficient. I found little oldish paper with similar topic at: http://www.vollmann.ch/en/pubs/cpp-excpt-alt.html and proposal from Mr.James Kanze about classic iostream design looks very reasonable for me, like: File f("foo.txt"); if(!f) // report an error Of course, I am not saying/(quering ideas) that this should be applied for all possible cases, but some really "exceptional" things (like memory exhaustion) should be left to the exceptions. I would thankfully accept any shared thoughts. Best, -- Sanel Zukan -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Tony on 27 Dec 2006 04:55 <sanelz(a)gmail.com> wrote in message news:1167152940.560632.62930(a)a3g2000cwd.googlegroups.com... > Greetings to all, > > I would like to ask, or hear some thoughts, if possible, about > exceptions > alternatives; 1.) Inform/Log/notify (what happened, the effect, what can be done about it) & terminate. 2.) Two phase construction (can't unhandably error in ctor and recover without exceptions). 3.) SetErrorHandler() style architecture (out of mem condition comes to mind). Use 1.) if can't handle. 4.) Check before you instantiate (such as file existence check if your constructor opens the file before you instantiate the File class). But this is basically 5.) below. 5.) Return/propogate an error indicator and possibly set an errno-like thing (in (platform-specific) thread local storage of course). Can't use in constructors. 6.) Program-specific or class-specific error handling (use the messaging system if available and "out of band" techniques like Watchdogs). 7.) setjmp/longjmp with/in a switch statement (seems too complex... see: "Exception Handling in C without C++" at http://www.on-time.com/ddj0011.htm). 8.) Make recovery easier by reserving resources to be made available when something pulls the rug out from under you. (Rhetorically: How critical is your application? ). This is a sub- technique. 9.) Pass in an error handling callback as an argument. n.) > I know this is very well discussed topic (with unclear > solutions at the end ;-)), but my search through groups archives didn't > yield any usefull solution, nor unfortunately, may popular books sais > anything about this in the details. > > The main reason I am writing this is because today's "modern view" for > library design looks like every possible error case should/must throw > some > kind of exception. Well much code looks like everything and anything should be templatized also. Don't use the advanced features of C++ until it hurts not to. Tony -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bjorn Reese on 27 Dec 2006 12:33 Tony wrote: > 1.) Inform/Log/notify (what happened, the effect, what can be done > about it) & terminate. > 2.) Two phase construction (can't unhandably error in ctor and recover > without exceptions). > 3.) SetErrorHandler() style architecture (out of mem condition comes > to mind). Use 1.) if can't handle. > 4.) Check before you instantiate (such as file existence check if your > constructor opens the file before you instantiate the File class). But > this is basically 5.) below. > 5.) Return/propogate an error indicator and possibly set an errno-like > thing (in (platform-specific) thread local storage of course). Can't use > in constructors. > 6.) Program-specific or class-specific error handling (use the > messaging system if available and "out of band" techniques like > Watchdogs). > 7.) setjmp/longjmp with/in a switch statement (seems too complex... > see: "Exception Handling in C without C++" at > http://www.on-time.com/ddj0011.htm). > 8.) Make recovery easier by reserving resources to be made > available when something pulls the rug out from under you. > (Rhetorically: How critical is your application? ). This is a sub- > technique. > 9.) Pass in an error handling callback as an argument. 10.) Return exploding return codes [1]. 11.) Return null-objects. [1] http://groups.google.dk/group/comp.lang.c++.moderated/browse_frm/thread/6466a3dfa2adf2b/8ab79ac447ccf31f -- mail1dotstofanetdotdk [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Tony on 28 Dec 2006 14:45 "Bjorn Reese" <breese(a)see.signature> wrote in message news:4592937d$0$4171$ba624c82(a)nntp02.dk.telia.net... > Tony wrote: > >> 1.) Inform/Log/notify (what happened, the effect, what can be done >> about it) & terminate. >> 2.) Two phase construction (can't unhandably error in ctor and recover >> without exceptions). >> 3.) SetErrorHandler() style architecture (out of mem condition comes >> to mind). Use 1.) if can't handle. >> 4.) Check before you instantiate (such as file existence check if your >> constructor opens the file before you instantiate the File class). But >> this is basically 5.) below. >> 5.) Return/propogate an error indicator and possibly set an errno-like >> thing (in (platform-specific) thread local storage of course). Can't use >> in constructors. >> 6.) Program-specific or class-specific error handling (use the >> messaging system if available and "out of band" techniques like >> Watchdogs). >> 7.) setjmp/longjmp with/in a switch statement (seems too complex... >> see: "Exception Handling in C without C++" at >> http://www.on-time.com/ddj0011.htm). >> 8.) Make recovery easier by reserving resources to be made >> available when something pulls the rug out from under you. >> (Rhetorically: How critical is your application? ). This is a sub- >> technique. >> 9.) Pass in an error handling callback as an argument. > 10.) Return exploding return codes [1]. > > [1] > http://groups.google.dk/group/comp.lang.c++.moderated/browse_frm/thread/6466a3dfa2adf2b/8ab79ac447ccf31f That is so cool! Kinda takes the wind out of the "relying on programmers to check return codes is wrought with peril" argument huh. If the goal is to avoid exceptions though, the destructor should just call a termination function rather than throwing. Also, it can't be used in constructors or for functions with C-linkage. I favor using zero as a return for failed functions and setting the error code elsewhere. That makes it easier to code: if( !my_func() ) // nice: exclamation point corresponds with error // handle error or propogate it back up the stack rather than: if( my_func() < 0 ) // handle error or propogate it back up the stack and rather than: if( my_func() ) // positive or negative values represent error // handle error or propogate it back up the stack > 11.) Return null-objects. How is that different from 5.)? Tony -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: sanelz on 29 Dec 2006 04:21
Hi, Tony, thanks for detailed answer. Btw. those exploding r.codes looks really cool ! > 1.) 2.) 4.) 5.) Already took into account, since these are classic ways for error handling. > 7.) Uh, I would like to avoid them :-) > How critical is your application? To be classic "server" model, runnable under any possible condition, no, but highly desirable to be resource light even in "exceptional" cases. Also in account in taken possibility for access from other languages. > Don't use the advanced features of C++ until it hurts not to. Anyone doing this, except to test latest versions of compilers? (just kidding) :-). > I favor using zero as a return for failed functions and setting the error code elsewhere Yes, this can be applied on objects too (given in my first post). So combining this with previous items (did I included callbacks into account?), and at top of that exploding codes as sugar, this can be really nice replacement for exceptions. I will explore them more. > the destructor should just call a termination function rather than throwing. Count me too for this. In this case, there is a programmer error, easily detected during tests, so I don't see any things should be saved/recovered. Sanel -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |