Smalltalk › Instantiations

Descriptions of Exceptions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

jtuchel

Descriptions of Exceptions

I keep complaining about Exceptions and stuff, although Instantiations has improved a lot about the mess exception handling had been a few releases before. The differences between instance based and class based exceptions have been ironed out quite nicely.

But still there is this issue with Exception descriptions I am having trouble with:

If you signal an Error like this:

Error signal: 'Landing impossible due to missing wheels'.

and the ask the resulting Signal for its description, you get

(ExError) an error has occurred.: Landing impossible due to missing wheels

If I want to use the #description to display it to end users, half the text is neither helpful nor poetic. It simply sucks, especially if my users do speak another language than english. They neither care about the class of the error, nor about an english sentence that says nothing more than there was an error.

Look at this example for a subclass of Error (no contract data found):

VertragsFehler signal: 'Keine Vertragsdaten gefunden'.

This results in:

(ExVertragsFehler) an error has occurred.: Keine Vertragsdaten gefunden.

Now imagine this message in a nicely animated Growl-like message box in a beautifully designed web application that is completely held in German. This is not acceptable to my users (at least my aesthetic self tells me so).

So #description now is well-done and works on all kinds of Exceptions and ExceptionalEvents and such. You don't have to dig into #arguments, #tag or #messageText or anything anymore. This is really great and I like how things have evolved in that area.

I've dug in a little bit and have seen that I can circumvent this mess if I make the ExceptionalEvent (which is held by the Exception internally) contain anything other than nil in its #description variable. But I know of now way to influence the contents of the internal ExceptionalEvent when I use class based exceptions.

So does anyone know if I can do something about this without going back to instance-based exceptions in my code?

The only thing I can do for now is override #description in my own subclasses, but then the system-provided Exceptions would still have the prefix. Another option would be to cut off the beginning of error messages up to the first colon. Which also sounds weird and wrong to me.

How do others solve this problem?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.

jtuchel

Re: Descriptions of Exceptions

So let me rephrase my question:

Am I the only one who has trouble with Error messages being prefixed by stupid text like "(ExError) an Error has occurred.:"?

If the answer is no, what do people do about it? Is there anything I can do to get rid of that (other than changing ExceptionalEvent>>#description)?

Thanks for comments/ideas,

Joachim

Richard Sargent

Re: Descriptions of Exceptions

Administrator

>> Am I the only one who has trouble with Error messages being prefixed by stupid text like "(ExError) an Error has occurred.:"?

Definitely not. Like you say, there was a lot more control of message display under the instance-based exceptions. I would like to see this improved, too.

On Tuesday, February 4, 2014 7:19:48 AM UTC-8, [hidden email] wrote:

So let me rephrase my question:

Am I the only one who has trouble with Error messages being prefixed by stupid text like "(ExError) an Error has occurred.:"?

If the answer is no, what do people do about it? Is there anything I can do to get rid of that (other than changing ExceptionalEvent>>#description)?

Thanks for comments/ideas,

Joachim

Hermann Ottens

Re: Descriptions of Exceptions

In reply to this post by jtuchel

Hi Joachim,

we solved it this way: define a new subclass of Error, then a new instance of ExceptionalEvent as child of ExError with an appropriate (german) description, then assigned it (#exceptionalEvent:) to the just created subclass of Error.
(Hope that it works for you, because we had to change the exception handling from class based to instance based, when we moved from VSE to VAST many years ago and there's still a lot of that old code around.)

Cheers,
Hermann

Am Dienstag, 28. Januar 2014 12:23:44 UTC+1 schrieb [hidden email]:

I keep complaining about Exceptions and stuff, although Instantiations has improved a lot about the mess exception handling had been a few releases before. The differences between instance based and class based exceptions have been ironed out quite nicely.

But still there is this issue with Exception descriptions I am having trouble with:

If you signal an Error like this:

Error signal: 'Landing impossible due to missing wheels'.

and the ask the resulting Signal for its description, you get

(ExError) an error has occurred.: Landing impossible due to missing wheels

If I want to use the #description to display it to end users, half the text is neither helpful nor poetic. It simply sucks, especially if my users do speak another language than english. They neither care about the class of the error, nor about an english sentence that says nothing more than there was an error.

Look at this example for a subclass of Error (no contract data found):

VertragsFehler signal: 'Keine Vertragsdaten gefunden'.

This results in:

(ExVertragsFehler) an error has occurred.: Keine Vertragsdaten gefunden.

Now imagine this message in a nicely animated Growl-like message box in a beautifully designed web application that is completely held in German. This is not acceptable to my users (at least my aesthetic self tells me so).

So #description now is well-done and works on all kinds of Exceptions and ExceptionalEvents and such. You don't have to dig into #arguments, #tag or #messageText or anything anymore. This is really great and I like how things have evolved in that area.

I've dug in a little bit and have seen that I can circumvent this mess if I make the ExceptionalEvent (which is held by the Exception internally) contain anything other than nil in its #description variable. But I know of now way to influence the contents of the internal ExceptionalEvent when I use class based exceptions.

So does anyone know if I can do something about this without going back to instance-based exceptions in my code?

The only thing I can do for now is override #description in my own subclasses, but then the system-provided Exceptions would still have the prefix. Another option would be to cut off the beginning of error messages up to the first colon. Which also sounds weird and wrong to me.

How do others solve this problem?

Joachim

jtuchel

Re: Descriptions of Exceptions

In reply to this post by jtuchel

Hi again,

While Hermanns suggestion works. I found it to be too much work and still not a perfect solution, because exceptions thrown by the system or third party libraries like glory would still present that useless prefix.

So I decided to use my big hammer for the problem, and I suggest this as a general solution for upcoming releases of VA Smalltalk. Here is what the method Signal>>#description looks like now:

| desc |

desc := self exception description.

^self messageText ifNil: [desc]

All I did was remove the ifNotNil part that would prefix the error text.

I am quite sure this is a solution that should be considered as a new implementation in VAST. One reason is that most applications I have seen append something to the text anyways for their GUI, a text like "Sorry, operation failed due to:".

The second reason is that I think this simplified implementation is much better in line with the method comment which says:

"Return text that describes in a human readable form an occurrence of an exception. If an explicit

message text was provided by the signaler of the exception, that text should be incorporated into

the description."

I think this new implementation fits much better with the comment, because a prefix like "(ExError) an error has occurred.: " does not really improve the readability for humans.

What do others think?

What does Instantiations think?

Joachim

Am Dienstag, 28. Januar 2014 12:23:44 UTC+1 schrieb [hidden email]:

I keep complaining about Exceptions and stuff, although Instantiations has improved a lot about the mess exception handling had been a few releases before. The differences between instance based and class based exceptions have been ironed out quite nicely.

But still there is this issue with Exception descriptions I am having trouble with:

If you signal an Error like this:

Error signal: 'Landing impossible due to missing wheels'.

and the ask the resulting Signal for its description, you get

(ExError) an error has occurred.: Landing impossible due to missing wheels

If I want to use the #description to display it to end users, half the text is neither helpful nor poetic. It simply sucks, especially if my users do speak another language than english. They neither care about the class of the error, nor about an english sentence that says nothing more than there was an error.

Look at this example for a subclass of Error (no contract data found):

VertragsFehler signal: 'Keine Vertragsdaten gefunden'.

This results in:

(ExVertragsFehler) an error has occurred.: Keine Vertragsdaten gefunden.

Now imagine this message in a nicely animated Growl-like message box in a beautifully designed web application that is completely held in German. This is not acceptable to my users (at least my aesthetic self tells me so).

So #description now is well-done and works on all kinds of Exceptions and ExceptionalEvents and such. You don't have to dig into #arguments, #tag or #messageText or anything anymore. This is really great and I like how things have evolved in that area.

I've dug in a little bit and have seen that I can circumvent this mess if I make the ExceptionalEvent (which is held by the Exception internally) contain anything other than nil in its #description variable. But I know of now way to influence the contents of the internal ExceptionalEvent when I use class based exceptions.

So does anyone know if I can do something about this without going back to instance-based exceptions in my code?

The only thing I can do for now is override #description in my own subclasses, but then the system-provided Exceptions would still have the prefix. Another option would be to cut off the beginning of error messages up to the first colon. Which also sounds weird and wrong to me.

How do others solve this problem?

Joachim

jtuchel

Re: Descriptions of Exceptions

Okay, big hammers are good for destroying stuff, but they hardly ever heal wounds.

In this case, my suggested fix is not appropriate, because now I get rubbish for some system exceptions like 'Index not found'. The error description now simply contains the index that I tried to access: The ExceptionalEvent's description is now: '1'. Which is a little short ;-)

So my problem is still unsolved... Other than Hermanns suggestion which excludes System exceptions. Maybe I just have to live with that for now...

Am Mittwoch, 12. Februar 2014 14:24:07 UTC+1 schrieb [hidden email]:

Hi again,

While Hermanns suggestion works. I found it to be too much work and still not a perfect solution, because exceptions thrown by the system or third party libraries like glory would still present that useless prefix.

So I decided to use my big hammer for the problem, and I suggest this as a general solution for upcoming releases of VA Smalltalk. Here is what the method Signal>>#description looks like now:

| desc |

desc := self exception description.

^self messageText ifNil: [desc]

All I did was remove the ifNotNil part that would prefix the error text.

I am quite sure this is a solution that should be considered as a new implementation in VAST. One reason is that most applications I have seen append something to the text anyways for their GUI, a text like "Sorry, operation failed due to:".

The second reason is that I think this simplified implementation is much better in line with the method comment which says:

"Return text that describes in a human readable form an occurrence of an exception. If an explicit
message text was provided by the signaler of the exception, that text should be incorporated into
the description."

I think this new implementation fits much better with the comment, because a prefix like "(ExError) an error has occurred.: " does not really improve the readability for humans.

What do others think?
What does Instantiations think?

Joachim

Am Dienstag, 28. Januar 2014 12:23:44 UTC+1 schrieb [hidden email]:
I keep complaining about Exceptions and stuff, although Instantiations has improved a lot about the mess exception handling had been a few releases before. The differences between instance based and class based exceptions have been ironed out quite nicely.

But still there is this issue with Exception descriptions I am having trouble with:

If you signal an Error like this:

Error signal: 'Landing impossible due to missing wheels'.

and the ask the resulting Signal for its description, you get

(ExError) an error has occurred.: Landing impossible due to missing wheels

If I want to use the #description to display it to end users, half the text is neither helpful nor poetic. It simply sucks, especially if my users do speak another language than english. They neither care about the class of the error, nor about an english sentence that says nothing more than there was an error.

Look at this example for a subclass of Error (no contract data found):

VertragsFehler signal: 'Keine Vertragsdaten gefunden'.

This results in:

(ExVertragsFehler) an error has occurred.: Keine Vertragsdaten gefunden.

Now imagine this message in a nicely animated Growl-like message box in a beautifully designed web application that is completely held in German. This is not acceptable to my users (at least my aesthetic self tells me so).

So #description now is well-done and works on all kinds of Exceptions and ExceptionalEvents and such. You don't have to dig into #arguments, #tag or #messageText or anything anymore. This is really great and I like how things have evolved in that area.

I've dug in a little bit and have seen that I can circumvent this mess if I make the ExceptionalEvent (which is held by the Exception internally) contain anything other than nil in its #description variable. But I know of now way to influence the contents of the internal ExceptionalEvent when I use class based exceptions.

So does anyone know if I can do something about this without going back to instance-based exceptions in my code?

The only thing I can do for now is override #description in my own subclasses, but then the system-provided Exceptions would still have the prefix. Another option would be to cut off the beginning of error messages up to the first colon. Which also sounds weird and wrong to me.

How do others solve this problem?

Joachim