Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news00.sunet.se!sunic!news.sprintlink.net!news.magicnet.net!news.supernet.net!news.cais.net!nntp.uio.no!usenet From: Jarle Stabell Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather Subject: Re: What Should An Exception Handling Do? -- Clarification of rules Date: 29 Mar 1996 17:54:22 GMT Organization: University of Oslo, Norway Lines: 57 Message-ID: <4jh84e$1b5@ratatosk.uio.no> References: <1996Mar25.160702.14229@schbbs.mot.com> NNTP-Posting-Host: pchf467.uio.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) To: shang@corp.mot.com Xref: news.daimi.aau.dk comp.object:53440 comp.lang.eiffel:22591 comp.lang.c++:175739 comp.lang.beta:10697 comp.lang.java:29820 comp.lang.sather:12378 shang@corp.mot.com (David L. Shang) wrote: >More examples: > > * the font does not exist and a query to the user is required to > get the substituting font; > * the input is in the wrong type and an input retry is required; > * the file is not associated with a default handler, would you > like to associate one and let me try to re-open the file? > * the format is not understood, would you suggest me a > converter? > * the embedded object is re-located, would give me the directory > to the new place? > >These conditions are not errors but only require some extraordinary work. >Similar examples were also given by Bill Foote in his previous post. >It is not hard for people to figure out more examples that requires the >following struture: > > result = try do_something() > { > when condition1: some_extraordinary_work1; retry; > when condition2: some_extraordinary_work2; retry; > when condition3: some_extraordinary_work3; retry; > when condition4: return null; > } > I think there's a problem with this "strategy", a user should be able to cancel this kind of operation, here some_extraordinary_work1..3 don't seem to give the user a chance to cancel the operation. I find this discussion regarding use of exceptions very interesting. I find myself a complete "dummy" regarding error-reporting/exception handling, and this disturbes me a lot because I otherwise look upon myself as an experienced programmer, but don't know how to systematically handle this elementary/everyday problem! (I don't think I'm the only one in this situation though.) Sometimes I find it comforting to know that a function returns a "nearly boolean" success-indicator (and doesn't fire any exceptions "outside of the callee"), so that an exception handler is not necessary to set up. But sometimes it is necessary to know more precisely what went wrong/happened. At least you sometimes have to propagate 'cancel'-"values". I view (Success, Failure), (Success, Failure, Cancel), (Success, Failure, Cancel, PretendSuccess/Ignore, InvalidPreconditions) etc as approximations of a true/big hierarchy of exception objects. Sometimes I find these approximations sufficient and easier to work with (f.i. defined as enumerated types, and returned to the caller). Since these "approximations" doesn't "jump" in the call-chain, they are approximations in a very limited sense. I would welcome any "eye-opener" on this issue, when should I use exceptions, when to use "old" status-values, when to "log/show" expections/errors (ako Windows NT event-log) in production systems, in debugging etc. (Dare I mention that I once wrote a parser that fired an expection when the Match-predicate didn't succeed?) I have read a good article written by Bertrand Meyer on the issue of exception handling, but it wasn't enough to "enlighten" me. I would welcome references to literature on this subject. Regards, Jarle