It's no good - there is something basic here that I can't get working.
Here is what I have now done.
In my methods module I have created a function with global scope
called processErrors(err as RuntimeException, where as String,
message as String), returning a String. In that function I have
pasted all of the if statements:
if err ISA AssertionException then
return "AssertionException"
elseif err ISA FunctionNotFoundException then
return "FunctionNotFoundException"
elseIf err ISA IllegalCastException then
return "IllegalCastException"
[etc]
(I know I am not making any use of the string arguments. I'm not that
far along!). But even before trying to write any code to use this
Function I get this error on compiling:
"There is no class with this name." next to the first line ("if err
ISA AssertException then")
You can see a couple of screenshots here, just to show that I'm not
imagining it:
http://www.tellura.co.uk/examples/rb_runtime_error_1.jpg
http://www.tellura.co.uk/examples/rb_runtime_error_2.jpg
I assume the message refers to AssertException since this is
highlighted in the bug window. Finally, the error is the same whether
the function signature is "err" or "Extends err".
I'm sure I'm doing something boneheaded, and I'm tearing out what
little remains of my hair...
Ian.
--
On 26 Feb 2007, at 4:04 am, Mark Levinson wrote:
>
> 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>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
