Xojo Conferences
MBSOct2019CologneDE

exception names (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: re: I have theories on how life should be
Next thread: App icon dock hiding? No way?


Another cross-plattform question   -   Jan Erik Moström <
  exception names   -   Lars Jensen
   Re: exception names   -   Charles Yeomans
    Re: exception names   -   Lars Jensen

exception names
Date: 31.05.02 05:54 (Fri, 31 May 2002 00:54:11 -0400)
From: Lars Jensen
So I decided to be a good citizen and use exception blocks. But I came
across a difficulty in making them generic and concise. Specifically, I
want to be able to say:

Sub Foo()
MakeAMess()

exception x
HandleException x
CleanUpTheMess()
End Sub

So far, so good. But I have implemented my own custom exception class.
So HandleException looks like this:

Sub HandleException(x as RuntimeException)
if x isA CustomException then
CustomException(x).TellUserAboutIt()
end if
End Sub

See the problem? If x isn't a CustomException, what do I do? I want to
put up a message to the user, but to make it meaningful I have to test
for each built-in exception type separately, which is not only inelegant
but downright obnoxious when you consider the truckload of new
exceptions in 4.5.

Or, in Foo() I could say:

exception x as CustomException
HandleException x
CleanUpTheMess()

which would handle my exception and still give me the generic exception
dialog for built-in ones, but then there's no way for me to call
CleanUpTheMess(). And if I say:

exception x as CustomException
HandleException x
CleanUpTheMess()
exception x
CleanUpTheMess()

then I don't get the built-in exception messages. Plus I hate the
repeated call to CleanUpTheMess(), because it's probably not one but
several lines that are cumbersome to turn into a method, and even the
one-liner version results in more bulk than I'd like.

This would be easy if RuntimeException could give me its own name --
then I could say:

Sub HandleException(x as RuntimeException)
if x isA CustomException then
CustomException(x).TellUserAboutIt()
else
msgbox "Exception: " + x.Name()
end if
End Sub

and be done with it. Am I missing something? If not, I'll REALbug a request.

lj

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: exception names
Date: 31.05.02 17:35 (Fri, 31 May 2002 12:35:22 -0400)
From: Charles Yeomans
You're not missing anything; you just need to write one big
If...ElseIf...End if block to associate a name with an exception class.
It's not ideal, but speed isn't really of the essence in this situation.

Charles Yeomans

On Friday, May 31, 2002, at 12:54 AM, Lars Jensen wrote:

> So I decided to be a good citizen and use exception blocks. But I came
> across a difficulty in making them generic and concise. Specifically, I
> want to be able to say:
>
> Sub Foo()
> MakeAMess()
>
> exception x
> HandleException x
> CleanUpTheMess()
> End Sub
>
> So far, so good. But I have implemented my own custom exception class.
> So HandleException looks like this:
>
> Sub HandleException(x as RuntimeException)
> if x isA CustomException then
> CustomException(x).TellUserAboutIt()
> end if
> End Sub
>
> See the problem? If x isn't a CustomException, what do I do? I want to
> put up a message to the user, but to make it meaningful I have to test
> for each built-in exception type separately, which is not only inelegant
> but downright obnoxious when you consider the truckload of new
> exceptions in 4.5.
>
> Or, in Foo() I could say:
>
> exception x as CustomException
> HandleException x
> CleanUpTheMess()
>
> which would handle my exception and still give me the generic exception
> dialog for built-in ones, but then there's no way for me to call
> CleanUpTheMess(). And if I say:
>
> exception x as CustomException
> HandleException x
> CleanUpTheMess()
> exception x
> CleanUpTheMess()
>
> then I don't get the built-in exception messages. Plus I hate the
> repeated call to CleanUpTheMess(), because it's probably not one but
> several lines that are cumbersome to turn into a method, and even the
> one-liner version results in more bulk than I'd like.
>
> This would be easy if RuntimeException could give me its own name --
> then I could say:
>
> Sub HandleException(x as RuntimeException)
> if x isA CustomException then
> CustomException(x).TellUserAboutIt()
> else
> msgbox "Exception: " + x.Name()
> end if
> End Sub
>
> and be done with it. Am I missing something? If not, I'll REALbug a
> request.
>
> lj
>
> ---
> Subscribe to the digest:
> <mailto:<email address removed>>
> Unsubscribe:
> <mailto:<email address removed>>


---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: exception names
Date: 31.05.02 19:51 (Fri, 31 May 2002 14:51:47 -0400)
From: Lars Jensen
> You're not missing anything; you just need to write one big
> If...ElseIf...End if block to associate a name with an exception class.
> It's not ideal, but speed isn't really of the essence in this situation.

Thanks for the reassurance.

Re-reading my mail, I realize that the problem is independent of whether
one has subclassed RuntimeException -- once you're in the exception
block, you have no access to exception names.

I guess I only have to write the big IF block once (per RB release), and
since it's in its own module I can re-use it with minimal pain. Except
that if I update it for 4.5, then I can't compile in 4.0 any more
without tweaking it. :(

I still think RB should make it unnecessary. If RuntimeException had a
.Name as string property, then I could not only get it but set it too,
and I wouldn't even need my custom subclass (since all it does is attach
a name). And if it had a constructor that allowed that property to be
passed, I could just say

raise new RuntimeException("this is what happened")

So that is what I will REALbug.

lj

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>