Re: Practical error/exception handling...

From: Raptor (bogus_at_none.com)
Date: 01/21/05 

Date: Thu, 20 Jan 2005 17:02:36 -0800

J West <jimw@fluffypaws.co.uk> wrote in message
news:ffCdndS4S8Vos23cRVnyvw@pipex.net...
> Hhmmmmm!
> What a lot of heat in this post!
> Could I humbly suggest that the requirement for a 'standard' way of
handling
> exceptions be iterated in order to get a better response.

And reiterated.

> i.e. state the problem rather than ask how to make the solution work!
>
> Anyway.

A problem well-stated is often well over half-solved. A corollary is that
people who don't understand something are often unsure how to frame the
question.

> What I have done in the past is to have a database table of error codes
for
> specific actions that I need to check for.
> e.g. When doing complicated updates that involve many tables (More than
> one!) then I define an error code for successfull update and I raise the
> error to a global error handling routine that can roll back transactions
and
> raise a standard message (That I can change without re-compile by updating
> the database) via a specially defined dialogue to tell the user that their
> data didn't save and to please report this message to me so I can
> rectify/investigate the problem. But I only need the exception handler in
> one save button click event handler because all my forms that save data
are
> descendants of this form.
>
> You see it's all in the design of the application as to how RAD and ROBUST
> your application really is.
>
> Good luck

So descendantship is one way to centralize error trapping code. That and a
list of anticipated problems.

Raptor