Smalltalk › Instantiations

Exceptions .. again!

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

jtuchel

Exceptions .. again!

Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/NQcD72RgbygJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

John O'Keefe-3

Re: Exceptions .. again!

Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
Return a textual description of the exception.

Definition: <exceptionDescription>
   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.

Return Value:
<readableString> unspecified

Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:

Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/Ilq7P67aOtIJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: Exceptions .. again!

Hi John,

thanks for helping me out of this.

I've come back to the same problem ever and ever and again and somehow had the feeling something's completely wrong about all this (and I wasn't sure if it was me).

Your suggested fix works as expected (note to readers: the method name is #description, not #definition). This raises the question whether you have plans to integrate it into the product, because, as you state, some people might have built workarounds for this that may not work any more (most likely they dive down the very same path from a Signal to its exception, so maybe it won't break much).

I'd vote in favor of adding it. Finally one and only one way to show a message Text for both kinds of exceptions...

I have another suggestion in addition to this: The prefix (ExError) An Error has occurred.: is information that might be helpful for developers, but not for users. I'd like to not show this to the user. So I'd like to have a chance to tell the exception handling mechanism to show this info or not. I can imagine two things: a global switch or a second method like userDescription. I'll add extensions for that to my own image, but this may be interesting for other users. The second approach would not be ANSI-compliant, though.

Joachim

Am Montag, 25. Juni 2012 22:59:30 UTC+2 schrieb John O'Keefe:

Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
   Return a textual description of the exception.
Definition: <exceptionDescription>
   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.
Return Value:
   <readableString> unspecified
Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:
Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/eN2R_TVIiBIJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: Exceptions .. again!

In reply to this post by John O'Keefe-3

John,

I'm coming back to this thread because somebody asked me a question about exceptions, after he'd tried examples from the VAST Programmers Reference manual. I was a bit surprised to see teh use of #newChild, because that is a message used in the context of instance based exception handling (what you call legacy). And in fact the Programmers Reference only talks about instance based exception handling.

Shouldn't the Programmers Reference discourage (or simply ignore) the use of instance-based exception handling?
And if class based exception handling is considered the technique to use in the future, I guess this should be described in the product dosumentation..

Or am I missing / misunderstaning something?

Joachim

Am Montag, 25. Juni 2012 22:59:30 UTC+2 schrieb John O'Keefe:

Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
   Return a textual description of the exception.
Definition: <exceptionDescription>
   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.
Return Value:
   <readableString> unspecified
Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:
Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/TSSi-BrU0VUJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

John O'Keefe-3

Re: Exceptions .. again!

Joachim -

You have not missed or misunderstood anything. Unfortunately, the doc is a little back-level on the subject of exceptions and exception handling.

John

On Wednesday, July 18, 2012 8:15:03 AM UTC-4, [hidden email] wrote:

John,

I'm coming back to this thread because somebody asked me a question about exceptions, after he'd tried examples from the VAST Programmers Reference manual. I was a bit surprised to see teh use of #newChild, because that is a message used in the context of instance based exception handling (what you call legacy). And in fact the Programmers Reference only talks about instance based exception handling.

Shouldn't the Programmers Reference discourage (or simply ignore) the use of instance-based exception handling?
And if class based exception handling is considered the technique to use in the future, I guess this should be described in the product dosumentation..

Or am I missing / misunderstaning something?

Joachim

Am Montag, 25. Juni 2012 22:59:30 UTC+2 schrieb John O'Keefe:
Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
   Return a textual description of the exception.
Definition: <exceptionDescription>
   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.
Return Value:
   <readableString> unspecified
Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:
Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/mLJsJzAMADgJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: Exceptions .. again!

John,

I guess my interest in exception handling sometimes sounds a bit like a fetish, but I've had (and am still having) so many difficulties to extract user-displayable information from all kinds of error signaling objects that I sometimes feel like sitting on a merry-go-round and all I thought I knew about exceptions gets messed up once again ;-)

The situation has improved and I hope with your newer versions of GLORP this will improve even a bit more. But still I sometimes need some place to come back to and look that stuff up...

The person who asked me about the exception stuff also cited a section from the Programmer's Reference (http://www.instantiations.com/docs/851/wwhelp/wwhimpl/js/html/wwhelp.htm#href=pr/stpr33.html) that also seems to be outdated in part:

All methods supporting the ANSI Smalltalk protocol are categorized as ANSI-API. Methods associated with ANSI Smalltalk function that is not complete in this release are categorized as ANSI-Unimplemented.

At the time of this writing, the following restrictions with respect to ANSI Smalltalk are in force:

1.	The following Exception methods are not functional

isNested

outer

pass

d.	resignalAs:

retry

f.	retryUsing: My impression is that at least #pass and #retry are implemented correctly on Signal, so without having tested it, I guess that is not true (any more?). Joachim

Am Mittwoch, 18. Juli 2012 15:52:07 UTC+2 schrieb John O'Keefe:

Joachim -

You have not missed or misunderstood anything. Unfortunately, the doc is a little back-level on the subject of exceptions and exception handling.

John

On Wednesday, July 18, 2012 8:15:03 AM UTC-4, [hidden email] wrote:
John,

I'm coming back to this thread because somebody asked me a question about exceptions, after he'd tried examples from the VAST Programmers Reference manual. I was a bit surprised to see teh use of #newChild, because that is a message used in the context of instance based exception handling (what you call legacy). And in fact the Programmers Reference only talks about instance based exception handling.

Shouldn't the Programmers Reference discourage (or simply ignore) the use of instance-based exception handling?
And if class based exception handling is considered the technique to use in the future, I guess this should be described in the product dosumentation..

Or am I missing / misunderstaning something?

Joachim

Am Montag, 25. Juni 2012 22:59:30 UTC+2 schrieb John O'Keefe:
Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
   Return a textual description of the exception.
Definition: <exceptionDescription>
   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.
Return Value:
   <readableString> unspecified
Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:
Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/r-8fGfiOZJQJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

John O'Keefe-3

Re: Exceptions .. again!

Joachim -

Yes, that page needs updating -- fixed in V8.5.2. The large issue of documentation of Exception handling will need to wait for the next release.

John
On Wednesday, July 18, 2012 4:34:52 PM UTC-4, [hidden email] wrote:

John,

I guess my interest in exception handling sometimes sounds a bit like a fetish, but I've had (and am still having) so many difficulties to extract user-displayable information from all kinds of error signaling objects that I sometimes feel like sitting on a merry-go-round and all I thought I knew about exceptions gets messed up once again ;-)

The situation has improved and I hope with your newer versions of GLORP this will improve even a bit more. But still I sometimes need some place to come back to and look that stuff up...

The person who asked me about the exception stuff also cited a section from the Programmer's Reference (http://www.instantiations.com/docs/851/wwhelp/wwhimpl/js/html/wwhelp.htm#href=pr/stpr33.html) that also seems to be outdated in part:

All methods supporting the ANSI Smalltalk protocol are categorized as ANSI-API. Methods associated with ANSI Smalltalk function that is not complete in this release are categorized as ANSI-Unimplemented.
At the time of this writing, the following restrictions with respect to ANSI Smalltalk are in force:
1.
The following Exception methods are not functional
a.
isNested
b.
outer
c.
pass
d.
resignalAs:
e.
retry
f.
retryUsing:

My impression is that at least #pass and #retry are implemented correctly on Signal, so without having tested it, I guess that is not true (any more?).

Joachim

Am Mittwoch, 18. Juli 2012 15:52:07 UTC+2 schrieb John O'Keefe:
Joachim -

You have not missed or misunderstood anything. Unfortunately, the doc is a little back-level on the subject of exceptions and exception handling.

John

On Wednesday, July 18, 2012 8:15:03 AM UTC-4, [hidden email] wrote:
John,

I'm coming back to this thread because somebody asked me a question about exceptions, after he'd tried examples from the VAST Programmers Reference manual. I was a bit surprised to see teh use of #newChild, because that is a message used in the context of instance based exception handling (what you call legacy). And in fact the Programmers Reference only talks about instance based exception handling.

Shouldn't the Programmers Reference discourage (or simply ignore) the use of instance-based exception handling?
And if class based exception handling is considered the technique to use in the future, I guess this should be described in the product dosumentation..

Or am I missing / misunderstaning something?

Joachim

Am Montag, 25. Juni 2012 22:59:30 UTC+2 schrieb John O'Keefe:
Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
   Return a textual description of the exception.
Definition: <exceptionDescription>
   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.
Return Value:
   <readableString> unspecified
Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:
Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/ob-jb2e38r8J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: Exceptions .. again!

In reply to this post by John O'Keefe-3

John,

I just saw that this change has not made its way into 8.5.2.

You didn't promise, but I was under the impression you had intended it to be in 8.5.2. Was I wrong?

I'm using it for quite a while now without any problems and am happy with the fact that at least some of my frustration with Exceptions and their descriptions is gone now.

So if I can, I vote for its inclusion in the next possible release

Joachim

Am Montag, 25. Juni 2012 22:59:30 UTC+2 schrieb John O'Keefe:

Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
   Return a textual description of the exception.
Definition: <exceptionDescription>
   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.
Return Value:
   <readableString> unspecified
Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:
Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/lX8ATsOD4GQJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: Exceptions .. again!

Hi again,

any word on whether this fix to #description will be integrated into newer versions of VA ST?
It works fine for me for a few months in two applications and it is very helpful.

I guess there will be little impact for existing code, because most projects I've seen have some complicated ifTrue:/ifFalse: special handling of #arguments and stuff on exceptions. These could all be removed and unified by using #description but the old code would still work.

Joachim

Am Montag, 8. Oktober 2012 15:06:53 UTC+2 schrieb [hidden email]:

John,

I just saw that this change has not made its way into 8.5.2.

You didn't promise, but I was under the impression you had intended it to be in 8.5.2. Was I wrong?
I'm using it for quite a while now without any problems and am happy with the fact that at least some of my frustration with Exceptions and their descriptions is gone now.

So if I can, I vote for its inclusion in the next possible release

Joachim

Am Montag, 25. Juni 2012 22:59:30 UTC+2 schrieb John O'Keefe:
Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
   Return a textual description of the exception.
Definition: <exceptionDescription>
   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.
Return Value:
   <readableString> unspecified
Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:
Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/FcXHnYMrxTMJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

John O'Keefe-3

Re: Exceptions .. again!

Joachim -

What you are seeing is a semantic difference in the APIs of class-based exceptions and instance-based exceptions -- not new information to you, I'm sure. It is unfortunate that #description crept into ANSI Exceptions with a different behavior than the instanced-based #description, but nothing can be done about that now.

For instance-based exceptions, #description has always answered a fixed string set when the ExceptionalEvent instance is created (see Handling of exceptions). The value passed when the exception is raised ('Could not do that because 15 screws are missing in the left wing') is available by sending #argument (same page reference) or #messageText (if you want to ensure it is a String) . There is no selector defined for instances of Signal that returns both values.

For class-based exceptions, the ANSI definition of #description 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." The VA Smalltalk implementation of this definition is <description> (see above) if there is no explicit message text and <description>': '<messageText> if there is explicit message text.

Obviously #description for instance-based exceptions COULD answer the same value as #description for class-based exceptions, and this is the easiest solution. The question is, should it answer the same value? If it is changed, then there is no API to answer the fixed description of instance-based exceptions, and it may present problems for code that expects a different answer. However, I don't see a good alternative to making this change if we want class- and instance-based exceptions to be interchangeable.

John

On Wednesday, December 12, 2012 7:51:37 AM UTC-5, [hidden email] wrote:

Hi again,

any word on whether this fix to #description will be integrated into newer versions of VA ST?
It works fine for me for a few months in two applications and it is very helpful.

I guess there will be little impact for existing code, because most projects I've seen have some complicated ifTrue:/ifFalse: special handling of #arguments and stuff on exceptions. These could all be removed and unified by using #description but the old code would still work.

Joachim

Am Montag, 8. Oktober 2012 15:06:53 UTC+2 schrieb [hidden email]:
John,

I just saw that this change has not made its way into 8.5.2.

You didn't promise, but I was under the impression you had intended it to be in 8.5.2. Was I wrong?
I'm using it for quite a while now without any problems and am happy with the fact that at least some of my frustration with Exceptions and their descriptions is gone now.

So if I can, I vote for its inclusion in the next possible release

Joachim

Am Montag, 25. Juni 2012 22:59:30 UTC+2 schrieb John O'Keefe:
Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
   Return a textual description of the exception.
Definition: <exceptionDescription>
   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.
Return Value:
   <readableString> unspecified
Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:
Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

jtuchel

Re: Exceptions .. again!

John,

I think we should get that change, because the way it is right now makes handling different kinds of Exceptions hard. As you stated before, both kinds of Exceptions will be around for a least "a while", and as a developer you can never be sure what to receive. So they need to be unified as much as possible.

There is only one alternative that would not break the ANSI standard: another method (unifiedErrorMessage or the like) that would neither harm any existing code nor force anything. It would, however, not help any existing code and its shortcomings as well.

AFAICT, there is a lot of ugly code out there trying to cope with the fact that some exceptions look different than others. Most of them fail in many situations anyways, so people just add more ifTrue's for new cases, trying to find something useful somewhere in the exception's or Signal's arguments or description or their custom workload added to their exception class/child.

You can try and take a look at Glorp to see how wrong things can go with Exceptions. And Glorp is not a really bad case... ;-)

If you want to stay close to the ANSI standard, it is probably best to make the non-ANSI-standard compliant instance-based exceptions as compliant as possible, even if that could be a bitter pill for existing VAST users. I suspect that the collateral damage wouldn't be too big, because #arguments etc. would still be there, so existing tumbles in exception handlers would still find what they are looking for. But these tumbles could be removed in existing code. New code wouldn't require these tumbles, so the world would look a little brighter without much effort ;-)

Joachim

Am Sonntag, 7. April 2013 19:15:25 UTC+2 schrieb John O'Keefe:

Joachim -

What you are seeing is a semantic difference in the APIs of class-based exceptions and instance-based exceptions -- not new information to you, I'm sure. It is unfortunate that #description crept into ANSI Exceptions with a different behavior than the instanced-based #description, but nothing can be done about that now.

For instance-based exceptions, #description has always answered a fixed string set when the ExceptionalEvent instance is created (see Handling of exceptions). The value passed when the exception is raised ('Could not do that because 15 screws are missing in the left wing') is available by sending #argument (same page reference) or #messageText (if you want to ensure it is a String) . There is no selector defined for instances of Signal that returns both values.

For class-based exceptions, the ANSI definition of #description 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." The VA Smalltalk implementation of this definition is <description> (see above) if there is no explicit message text and <description>': '<messageText> if there is explicit message text.

Obviously #description for instance-based exceptions COULD answer the same value as #description for class-based exceptions, and this is the easiest solution. The question is, should it answer the same value? If it is changed, then there is no API to answer the fixed description of instance-based exceptions, and it may present problems for code that expects a different answer. However, I don't see a good alternative to making this change if we want class- and instance-based exceptions to be interchangeable.

John

On Wednesday, December 12, 2012 7:51:37 AM UTC-5, [hidden email] wrote:
Hi again,

any word on whether this fix to #description will be integrated into newer versions of VA ST?
It works fine for me for a few months in two applications and it is very helpful.

I guess there will be little impact for existing code, because most projects I've seen have some complicated ifTrue:/ifFalse: special handling of #arguments and stuff on exceptions. These could all be removed and unified by using #description but the old code would still work.

Joachim

Am Montag, 8. Oktober 2012 15:06:53 UTC+2 schrieb [hidden email]:
John,

I just saw that this change has not made its way into 8.5.2.

You didn't promise, but I was under the impression you had intended it to be in 8.5.2. Was I wrong?
I'm using it for quite a while now without any problems and am happy with the fact that at least some of my frustration with Exceptions and their descriptions is gone now.

So if I can, I vote for its inclusion in the next possible release

Joachim

Am Montag, 25. Juni 2012 22:59:30 UTC+2 schrieb John O'Keefe:
Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
   Return a textual description of the exception.
Definition: <exceptionDescription>
   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.
Return Value:
   <readableString> unspecified
Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:
Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim

John O'Keefe-3

Re: Exceptions .. again!

Joachim -

OK, I will make the change and write-up the Migration Guide page.

You had asked about a more user-friendly version of #description -- it already exists, try #messageText.

John
On Monday, April 8, 2013 5:36:53 AM UTC-4, [hidden email] wrote:

John,

I think we should get that change, because the way it is right now makes handling different kinds of Exceptions hard. As you stated before, both kinds of Exceptions will be around for a least "a while", and as a developer you can never be sure what to receive. So they need to be unified as much as possible.

There is only one alternative that would not break the ANSI standard: another method (unifiedErrorMessage or the like) that would neither harm any existing code nor force anything. It would, however, not help any existing code and its shortcomings as well.

AFAICT, there is a lot of ugly code out there trying to cope with the fact that some exceptions look different than others. Most of them fail in many situations anyways, so people just add more ifTrue's for new cases, trying to find something useful somewhere in the exception's or Signal's arguments or description or their custom workload added to their exception class/child.

You can try and take a look at Glorp to see how wrong things can go with Exceptions. And Glorp is not a really bad case... ;-)

If you want to stay close to the ANSI standard, it is probably best to make the non-ANSI-standard compliant instance-based exceptions as compliant as possible, even if that could be a bitter pill for existing VAST users. I suspect that the collateral damage wouldn't be too big, because #arguments etc. would still be there, so existing tumbles in exception handlers would still find what they are looking for. But these tumbles could be removed in existing code. New code wouldn't require these tumbles, so the world would look a little brighter without much effort ;-)

Joachim

Am Sonntag, 7. April 2013 19:15:25 UTC+2 schrieb John O'Keefe:
Joachim -

What you are seeing is a semantic difference in the APIs of class-based exceptions and instance-based exceptions -- not new information to you, I'm sure. It is unfortunate that #description crept into ANSI Exceptions with a different behavior than the instanced-based #description, but nothing can be done about that now.

For instance-based exceptions, #description has always answered a fixed string set when the ExceptionalEvent instance is created (see Handling of exceptions). The value passed when the exception is raised ('Could not do that because 15 screws are missing in the left wing') is available by sending #argument (same page reference) or #messageText (if you want to ensure it is a String) . There is no selector defined for instances of Signal that returns both values.

For class-based exceptions, the ANSI definition of #description 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." The VA Smalltalk implementation of this definition is <description> (see above) if there is no explicit message text and <description>': '<messageText> if there is explicit message text.

Obviously #description for instance-based exceptions COULD answer the same value as #description for class-based exceptions, and this is the easiest solution. The question is, should it answer the same value? If it is changed, then there is no API to answer the fixed description of instance-based exceptions, and it may present problems for code that expects a different answer. However, I don't see a good alternative to making this change if we want class- and instance-based exceptions to be interchangeable.

John

On Wednesday, December 12, 2012 7:51:37 AM UTC-5, [hidden email] wrote:
Hi again,

any word on whether this fix to #description will be integrated into newer versions of VA ST?
It works fine for me for a few months in two applications and it is very helpful.

I guess there will be little impact for existing code, because most projects I've seen have some complicated ifTrue:/ifFalse: special handling of #arguments and stuff on exceptions. These could all be removed and unified by using #description but the old code would still work.

Joachim

Am Montag, 8. Oktober 2012 15:06:53 UTC+2 schrieb [hidden email]:
John,

I just saw that this change has not made its way into 8.5.2.

You didn't promise, but I was under the impression you had intended it to be in 8.5.2. Was I wrong?
I'm using it for quite a while now without any problems and am happy with the fact that at least some of my frustration with Exceptions and their descriptions is gone now.

So if I can, I vote for its inclusion in the next possible release

Joachim

Am Montag, 25. Juni 2012 22:59:30 UTC+2 schrieb John O'Keefe:
Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
   Return a textual description of the exception.
Definition: <exceptionDescription>
   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.
Return Value:
   <readableString> unspecified
Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:
Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim

jtuchel

Re: Exceptions .. again!

John,

I'll take a look at #messageText - thanks for your tip.

And also thanks a lot for integrating the fix from this thread into the product. It's small but dissolves a lot of trouble!

Joachim

Am Montag, 8. April 2013 17:53:39 UTC+2 schrieb John O'Keefe:

Joachim -

OK, I will make the change and write-up the Migration Guide page.

You had asked about a more user-friendly version of #description -- it already exists, try #messageText.

John
On Monday, April 8, 2013 5:36:53 AM UTC-4, [hidden email] wrote:
John,

I think we should get that change, because the way it is right now makes handling different kinds of Exceptions hard. As you stated before, both kinds of Exceptions will be around for a least "a while", and as a developer you can never be sure what to receive. So they need to be unified as much as possible.

There is only one alternative that would not break the ANSI standard: another method (unifiedErrorMessage or the like) that would neither harm any existing code nor force anything. It would, however, not help any existing code and its shortcomings as well.

AFAICT, there is a lot of ugly code out there trying to cope with the fact that some exceptions look different than others. Most of them fail in many situations anyways, so people just add more ifTrue's for new cases, trying to find something useful somewhere in the exception's or Signal's arguments or description or their custom workload added to their exception class/child.

You can try and take a look at Glorp to see how wrong things can go with Exceptions. And Glorp is not a really bad case... ;-)

If you want to stay close to the ANSI standard, it is probably best to make the non-ANSI-standard compliant instance-based exceptions as compliant as possible, even if that could be a bitter pill for existing VAST users. I suspect that the collateral damage wouldn't be too big, because #arguments etc. would still be there, so existing tumbles in exception handlers would still find what they are looking for. But these tumbles could be removed in existing code. New code wouldn't require these tumbles, so the world would look a little brighter without much effort ;-)

Joachim

Am Sonntag, 7. April 2013 19:15:25 UTC+2 schrieb John O'Keefe:
Joachim -

What you are seeing is a semantic difference in the APIs of class-based exceptions and instance-based exceptions -- not new information to you, I'm sure. It is unfortunate that #description crept into ANSI Exceptions with a different behavior than the instanced-based #description, but nothing can be done about that now.

For instance-based exceptions, #description has always answered a fixed string set when the ExceptionalEvent instance is created (see Handling of exceptions). The value passed when the exception is raised ('Could not do that because 15 screws are missing in the left wing') is available by sending #argument (same page reference) or #messageText (if you want to ensure it is a String) . There is no selector defined for instances of Signal that returns both values.

For class-based exceptions, the ANSI definition of #description 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." The VA Smalltalk implementation of this definition is <description> (see above) if there is no explicit message text and <description>': '<messageText> if there is explicit message text.

Obviously #description for instance-based exceptions COULD answer the same value as #description for class-based exceptions, and this is the easiest solution. The question is, should it answer the same value? If it is changed, then there is no API to answer the fixed description of instance-based exceptions, and it may present problems for code that expects a different answer. However, I don't see a good alternative to making this change if we want class- and instance-based exceptions to be interchangeable.

John

On Wednesday, December 12, 2012 7:51:37 AM UTC-5, [hidden email] wrote:
Hi again,

any word on whether this fix to #description will be integrated into newer versions of VA ST?
It works fine for me for a few months in two applications and it is very helpful.

I guess there will be little impact for existing code, because most projects I've seen have some complicated ifTrue:/ifFalse: special handling of #arguments and stuff on exceptions. These could all be removed and unified by using #description but the old code would still work.

Joachim

Am Montag, 8. Oktober 2012 15:06:53 UTC+2 schrieb [hidden email]:
John,

I just saw that this change has not made its way into 8.5.2.

You didn't promise, but I was under the impression you had intended it to be in 8.5.2. Was I wrong?
I'm using it for quite a while now without any problems and am happy with the fact that at least some of my frustration with Exceptions and their descriptions is gone now.

So if I can, I vote for its inclusion in the next possible release

Joachim

Am Montag, 25. Juni 2012 22:59:30 UTC+2 schrieb John O'Keefe:
Joachim -

There are (and probably always will be) 2 different exception implementations -- instance-based legacy (ExceptionalEvent) and class-based ANSI (Exception). Currently a class-based exception turns itself into an instance-based exception when it is signalled.

The new modern way to handle exceptions is with class-based exceptions, but I have tried very hard to make it so you can't tell from the outside which kind of exception was used. Migrating the instance-based exceptions to class-based is a fairly low-priority task at the moment.

For class-based exceptions, #description does what you want ((ExError) An error has occurred.: Could not do that because 15 screws are missing in the left wing); unfortunately, for instance-based exceptions, it does what you see (which is the legacy instance-based behavior).

Here is a replacement method for Signal>>#definition that should give you what you want for both kinds of exceptions:

description
"Synopsis:
   Return a textual description of the exception.
Definition: <exceptionDescription>
   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.
Return Value:
   <readableString> unspecified
Errors:
   none
  Implementation Notes:
Promoted from Exception."

| desc |

desc := self exception description.
^ self messageText
  ifNil: [ desc ]
  ifNotNil: [ :mt | desc, ': ', mt ]

Of course, this change to Signal>>#definition will probably cause someone somewhere a migration issue.

John

On Monday, June 25, 2012 4:07:06 PM UTC-4, [hidden email] wrote:
Hi again,

I am again baffled, puzzled, helpless and lost with Exception Handling in VA Smalltalk, especially when it comes to getting a human readable description form an Exception or an ExceptionalEvent.

So I'd like to learn and understand one last and terminal time what's the preferred way of throwing exceptions, giving them a human-readable error description and finally displaying it to my application's users.

My understanding so far is that the method #description is what I am looking for if I want to show the message text to my users.

Please take a look at the following code snippet:

[
    self error: 'Could not do that because 15 screws are missing in the left wing'.
    ] on: ExError do: [:ex |
        Transcript cr; cr; show: ex description.
        ex exitWith: nil]

I would expect this to display my message text, but what it shows is a stupid

(ExError) An error has occurred.

What the heck do the users of my (web) application learn from this message? I guess nothing more than that I am a complete nerdy idiot who wants hs users to go elsewhere.

This drives me really mad. Do I really have to write isKindOf: tests for all kinds of exceptions to simply get the text I want?

To me it seems that Exception>>#description does exactly what I'd want, but Object>>#error: doesn't use Exception, but ExceptionalEvent or Error.
Not only is it irritating that there are two separate class hierarchoes, but also is it enerving that the behave differently and seem to both be used in system classes and appliocation code.

I seem to remember that the two separate hierarchies stem from the fact that VAST once supported another approach than the ANSI standard promotes (Class vs. Instance based exceptions), and I seem to remember I read somewhere that the transition was complete. So is it really?
Which one is it and is there a schedule for deprecating the old one? If so, could we at least have one unique way of asking both for their message text for the time in-between?

So how do people handle this problem in their code and what does Instantiations plan to do in this area?

Or is it just my fault and I shouldn't be using #description?
Or should I avoid #error: ? This is hardly possible: VA ST uses it as well, so I have to live with the results of error: anyways.

Joachim