On Feb 24, 2007, at 1:03 PM, Ian Piper wrote:
>
> but then I'd need to add else clauses for all types of Exception -
> rather ungainly.
Ian:
Joe Huber provides a nice method for abstracting the type of
exception into a global method.
Taking this as an example, you should consider abstracting your
exception handling so that
your code is not cluttered with ungainly levels of "if-then-else"
statements for the various
exception types.
You could create a method that takes an exception, breaks it down
similar
to the way Joe illustrated, and then acted on the exception type.
If your method takes
a few string parameters as well, then you pass the exception as well
as some explanation of what happened.
Now you can make log entries and other actions using the
strings passed into the global method. But you only need to
write this method once, and then
call it from any location in your code.
Modifying Joes' example:
Function processError (err as RuntimeException, where as string,
explanation as string)
....
....
....
elseIf err ISA IllegalCastException then
System.Log where + ": " + "IllegalCastException " +
explanation + Chr(13)
End Function
In your code, you now can just say:
processError(err, "thisMethodName", "trying to open a database
file from disk")
If you drop these types of calls into try/catch statements, you can
customize your error handling
by catching each error and sending a customized information to your
logging method, and yet
your code is modular, concise, readable, and with very few redundant
statements.
Mark Levinson, MD
Hutchinson, KS
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
