Practical error/exception handling...

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

Date: Tue, 18 Jan 2005 20:09:04 -0800

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

Quantcast