Re: Looking for Tips/Writeup on overall approach to Exception Processing

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

"Rex" <RexForum4453@xxxxxxxxxxxxxxxxxx> wrote in message
news:2pug63dvpatk2je52gk6l6nnbbjhg6gm1j@xxxxxxxxxx

Re: Looking for Tips/Writeup on overall approach to Exception
Processing

I think it would be useful for you to have a look at "Design By Contract".
Although I have reservations about it as a design approach, the concept of
contracts on which it is built is a good way of thinking about how to use
exceptions.

So here goes: Let's say most or all of my Application's methods
return a bool to indicate whether the routine successfully completed
or not. The bool will be equal to "false" ONLY if there is a logic
error or system error - never due to some invalid input from the User
and never, for example, because a User file is not found. Does it make
sense to do it this way?

Probably not. Think about what the method should do, and what conditions
have to apply for it to succeed in doing that. Document those conditions
(the "preconditions")and require the client to make sure they apply, at
least insofar as the client can. For debugging check that the client /has/
met the preconditions and throw an exception if they haven't. If it's an
exposed interface (eg, a library interface) consider leaving the check in
the the released version. Debugging or not, if the preconditions are met and
the method fails to do what it promises, raise an exception.

That's not the be-all and end-all of exception handling, but it's a good
start.

And if so, should the calling routine always
check for this "false" value on all called methods??? (which could be
alot of code!)

Which is one big advantage of exceptions.

And should the error message that the User sees always
come from the called routine?

Another big advantage of exceptions is that they can be handled at an
appropriate level. A low level method might have no idea about what it's
being used for, and so has no change of producing a message that's
meaningful to the user in the context of what they were trying to do. Let
the exception propogate up to a higher level, and the application can
account for what it was trying to achieve with the lower level call, and
what it means to the user. Then you can give an error message in the
/user's/ terms, not in the /program's/ terms (if the error looks like being
a logic error, though, consider making the exception trace available to the
user in a form that they can easily report back to you, such as an error log
file that they can email to you).

Any error message that a low-level method can generate is almost certainly
useless to a user, and will probably only serve to annoy them.

And does this mean I would implement a
Try block in every called method??? I would very much appreciate
anyone who can help me sort all of this out... which brings me to...

No. You only catch an exception if you are in a position to do something
useful with it.

3. Does anyone know of any document on the Web with some tips and/or
suggested overall approaches to Exception Processing?

This thread? ;-)


.

Relevant Pages

  • Re: The origins of CL conditions system
    ... Machine experience explaining the Lisp Machine error handling. ... languages with continuable exceptions (including Mary Fontana from TI ... Why can't I resume after catching an exception? ... exception handling chapter of The Design and Evolution of C++. ...
    (comp.lang.lisp)
  • Re: CInternetSession
    ... the presence of the Sleepindicates the serious design flaw. ... Sleep() calls around like pixie dust, your design is fundamentally broken and will need to ... If you use Sleepin a loop, your design is probably wrong and needs to be ... The "First Chance Exception" message usually indicates nothing harmful. ...
    (microsoft.public.vc.mfc)
  • Re: [announcement] SYSAPI and SYSSVC for Windows
    ... Windows is the actual design problem, ... exception would just have to be a tagged type. ... Observe that the following is absolutely legal and works in Ada: ... The compiler checks that Data_Error cannot propagate out of f. ...
    (comp.lang.ada)
  • Re: Anonymus functions revisited
    ... > If the exception is the problem, ... Why should we assume the concept or design ... Suppose we have an algoritme ... > of lambda, at least not in this example. ...
    (comp.lang.python)
  • Re: Python from Wise Guys Viewpoint
    ... The default behaviour of the system was to abort the mission ... > flight would be to leave a program exception unhandled. ... This is a serious design error, not a problem of the programming language. ...
    (comp.lang.lisp)