Re: Practical error/exception handling...

From: J West (jimw_at_fluffypaws.co.uk)
Date: 01/20/05 

Date: Thu, 20 Jan 2005 22:28:41 -0000

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.
i.e. state the problem rather than ask how to make the solution work!

Anyway.

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

Regards

James West.

"Raptor" <bogus@none.com> wrote in message
news:cskmju02lvc@news2.newsguy.com...
> OK, suppose we wish to write an application that handles errors gracefully
> and is informative to both user and developer when errors occur. (Hey,
> don't
> laugh, it COULD happen! Heh.)
>
> As I understand it, this is essentially usable code for handling errors
> with
> some grace, except that one might call a handler instead of popping up a
> message from the procedure:
>
> procedure TformMain.Button1Click(Sender: TObject);
> begin
> Try
> // Do stuff here which requires cleanup...
> Try
> Memo1.Lines.LoadFromFile('nosuch.txt');
> Except
> On E: Exception do
> begin
> ShowMessage('Button1Click: ' + E.Message);
> end
> end;
> Finally
> // Cleaning up
> end;
> end;
>
> A few questions:
>
> Would this sort of code be used in ALL procedures and functions of
> consequence, or just selected ones? If the latter, how does one decide
> where
> to place such traps?
>
> In practice, could using these liberally offer feedback to the software
> manufacturer as to where IN CODE problems are arising for users? If so,
> what's a good practice for messages which might help the developer without
> annoying the user?
>
> Does one place the string constants in each code location, as I've done in
> this instance, or would localization (internationalization) issues (or
> code
> organization) prompt one to collect it in one place for easier translation
> or management?
>
> After several hours looking, I've been unable to locate code which would
> exemplify a really good overall strategy for managing this. Plenty of
> tutorials and code scraps at the procedure/function level, but nothing
> more
> abstract at the application level.
>
> Any thoughts or links? I'm at the point in developing my application
> framework where error bulletproofing is demanding attention, as it won't
> be
> easier down the road.
>
> Raptor
>
>