Exception alternatives
in [C++]
|
Prev: CRTP question
Next: BinaryPredicate Question
From: Bjorn Reese on 29 Dec 2006 16:46 Tony wrote: > "Bjorn Reese" <breese(a)see.signature> wrote in message > news:4592937d$0$4171$ba624c82(a)nntp02.dk.telia.net... > >>Tony wrote: >>>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. >>11.) Return null-objects. > > > How is that different from 5.)? Null-objects are no-operation objects that can be used as normal objects, so you do not need to add error handling code. They are like NaN floating-point values. See: http://citeseer.ist.psu.edu/woolf96null.html -- mail1dotstofanetdotdk [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Tony on 31 Dec 2006 13:51 "Bjorn Reese" <breese(a)see.signature> wrote in message news:459540e0$0$4164$ba624c82(a)nntp02.dk.telia.net... > Tony wrote: >> "Bjorn Reese" <breese(a)see.signature> wrote in message >> news:4592937d$0$4171$ba624c82(a)nntp02.dk.telia.net... >> >>>Tony wrote: > >>>>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. > >>>11.) Return null-objects. >> >> >> How is that different from 5.)? > > Null-objects are no-operation objects that can be used as normal > objects, so you do not need to add error handling code. To me that sounds like ignoring errors or even masking them. What am I missing? Unless you just mean comparing against a known null object (a technique of providing default reference arguments to functions) in which case it is like 5.). > They are like > NaN floating-point values. See: > > http://citeseer.ist.psu.edu/woolf96null.html 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 1 Jan 2007 10:47 Tony wrote: > To me that sounds like ignoring errors or even masking them. What Yes, null-objects are deliberately masking errors. It is not a general substitute for exceptions, but it does offer a solution where errors may be ignored. > am I missing? Unless you just mean comparing against a known > null object (a technique of providing default reference arguments to > functions) in which case it is like 5.). I do not. -- mail1dotstofanetdotdk [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Lance Diduck on 2 Jan 2007 11:44 sanelz(a)gmail.com wrote: > 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 Exceptions say "Things from this point on just wont make any sense. Go back and try again" Most errors are cases of expecting too much from a functions and classes. For example, you can do this: void readdata(std::string const&filename); //cant open file, must be exception //almost no other way to handle this error (other than return codes) //but bad filenames are a fact of life However, a slight change in design of what the function expects and you can change the error mechanism easily void readdata(std::streambuf&_file); //must give this an opened file to a real streambuf //throws only if stream passed in is not is a good state initially, //i.e. program not constructed properly //no return codes etc needed std:ifstream f("filename"); if(f)readdata(*f.rdbuf()); else "Error"; This is just a small example that the best alternative to exceptions is by making function precondition checks into class invariants -- place the function precondition checks into little classes, and these little class become the function arguments. This has the effect of pushing up the check closer to where the error actually occured. This drastically reduces the number of things that need to be handled by exceptions. See http://www.lancediduck.com/papers/Cpp/UsingOOwithCPP2.htm#_Toc89666392 -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: sanelz on 3 Jan 2007 14:40
> Exceptions say "Things from this point on just wont make any sense. Go > back and try again" I would add a small practical view; they try (uh, these "try" :-)) to say that, but IMHO in large percent of cases, they just shut down the system in a nice way. On other hand, PORC (plain-old-return-codes) do exactly that. Many will probably argue that exceptions introduce readable code too, but does it really? Here are few samples: 1) // open file and do the rest f.open("/home/baz/foo.txt"); if(!f.opened()) { // ups, user moved it, try with system wide f.open("/etc/foo.txt"); // checks... } This can be squeezed with return code from 'open()', so one-liner will do the job: if(!f.open("/home/baz/foo.txt") && !f.open("/etc/foo.txt") // report error, exit 2) try { // construct f f.open("/home/baz/foo.txt"); } catch(FileError& e) { // failed ? // how to open /etc/foo.txt in a clean way ??? } For ordinary programmer 1) sample is much logic and readable. Not to say for code like this: try { File f; // ... Socket s; // ... Database d; // ... // rest 100 lines } // catch part Anyone at first code view knows who throwed exception? Of course, good old debugger will yield usefull information, but doesn't that applies for assertions too ? Recently I got under my hands a piece of software which throw on everything. Apparently software author (who is coming with java background), is as seems to, very amazed with exceptions, so he filled every "highly-possible-error" line with some throw. This is nice, but at the end, even he forgot to catch some of them. So how would end user report an usefull error when he/she got a sweet "Abort" and nothing else? At the end, assert will at least report offended line, so at least you will know where to look. > Most errors are cases of expecting too much Yes. Seems programmers these days like to write one-line black boxes that do the magic (open, read, make a coffee etc.). In one article, someone said: "let we write the code, and errors leave to the compiler", with exceptions in topic. This is very sad, since with this view, people get false security. > http://www.lancediduck.com/papers/Cpp/UsingOOwithCPP2.htm#_Toc89666392 I quickly scanned, and IMHO Account sample with assertions, at least for me, looks much better. Reasons? People often just skim documentation, and line with "this can throw" is probably the last thing they will notice; so forgetting try{}catch pair is often. Sanel -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |