How to display an error message properly?

I think I came up with this topic before - either here or on my blog.

--
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/-/O20stYqWDvoJ.
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.

Same idea, same feeling, same problems .....

--
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/-/8nwc82Ok27AJ.
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.

Okay, I am back with this topic, because it really makes software maintenance hard and costs a lot of type checking and stuffon exceptions, just to show some useful information to the user and thus give the support staff some kind of useful information for their search for a bug.

What was the problem again?

The main problem is that there seems to be no one method across all kinds of exceptions that you can use to display error information. All kinds of signals and exceptions have their user-readable information accessible through different methods.

Why is it a problem?

Because if you want to show error information to the user of an application, there is no unique way to say anything more helpful than "An Exception Occured!". The real calories of an exception or signal lie buried in some variable in some embedded Exception's variable. Unfortunately, this variable is not the same for all Exception types, neither within code shipped by Instantiations, nor within 3rd party code.
This is not only a problem for the case where some user out in the field gets an error popup and cannot tell the maintenance guys what actually happened, but even as a developer you often have to dig around in the debugger for a while until you get anything more specific than "Signal on Exception: an exception has occured". This costs real time, nerves and therefor $$$MONEY$$$.

What does Joachim think Instantiations can and should do?

Step 1: Postulate a new standard method that each kind of Signal / Exception should answer with a user-readable and helpful descritpion of the problem.

Step 2: Consolidate all supported frameworks and libraries that ship with VAST to have this standard method answer useful info. This may be by using the individual existing methods that answer the correct string.

Step 2a:  Encourage third parties (tool vendors, goodie authors, o/s port maintainers) to implement that new standard method.

What does Joachim think we as a Community can do?

We cannot do much about Step 1 other than nagging Instantiations here and in support cases. Once Step 1 is made, we can do a lot about Step 2a: comb through our goodies and ported code and (re-)implement or error handling code.

Why does Joachim think this is of any use to anybody?

Because I can't believe I am the only person who is tired of writing lots of [:ex| ex isKindOf: ... ifTrue:[] ifFalse: []] cascades in handlers and still having lots of cases where the application simply says: "I know something went wrong but I won't tell you!"
Maybe many projects out there that have existed for 15 years or more have their own solutions for this kind of problem (one giant bloated block filled with ifTrue:s, but for new projects this is just another expensive hurdle that needs to be taken. A simple thing gets hard and tiresome in the existing code base.

Thanks for reading and commenting

Joachim


Am Dienstag, 25. Oktober 2011 22:28:40 UTC+2 schrieb [hidden email]:

I think I came up with this topic before - either here or on my blog.

What do people do to display a proper error message? Whatever method I try to use to extract user-readable info from exceptions and signals, there are always cases in which the error message will be useless nonsense like "An exception has occured" rather than the actual error message. 

It seems there is no unified method to access the error message of Exceptions that are wrapped in a Signal end such. I've skimmed through some customers' code as well and it seems everybody seems to break themselves a few dozen legs on their way to the info they want to display. Lots of isKindOf: and such, but nobody seems to have a real solution.

So is there a message common to all exceptions and signals that will allow me to display an error message? And if not, why not put in on the todo-list for V8.51?

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/-/VAtK4QkA76gJ.
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.

Small addition to Step 2:
* Change the Debugger to use this method by default in the next release of VAST. This implies that there needs to be some kind of default implementation of this method in ExceptionalEvent or even Object that displays at least the same text as today.

Am Mittwoch, 11. April 2012 10:48:51 UTC+2 schrieb [hidden email]:

Okay, I am back with this topic, because it really makes software maintenance hard and costs a lot of type checking and stuffon exceptions, just to show some useful information to the user and thus give the support staff some kind of useful information for their search for a bug.

What was the problem again?

The main problem is that there seems to be no one method across all kinds of exceptions that you can use to display error information. All kinds of signals and exceptions have their user-readable information accessible through different methods.

Why is it a problem?

Because if you want to show error information to the user of an application, there is no unique way to say anything more helpful than "An Exception Occured!". The real calories of an exception or signal lie buried in some variable in some embedded Exception's variable. Unfortunately, this variable is not the same for all Exception types, neither within code shipped by Instantiations, nor within 3rd party code.
This is not only a problem for the case where some user out in the field gets an error popup and cannot tell the maintenance guys what actually happened, but even as a developer you often have to dig around in the debugger for a while until you get anything more specific than "Signal on Exception: an exception has occured". This costs real time, nerves and therefor $$$MONEY$$$.

What does Joachim think Instantiations can and should do?

Step 1: Postulate a new standard method that each kind of Signal / Exception should answer with a user-readable and helpful descritpion of the problem.

Step 2: Consolidate all supported frameworks and libraries that ship with VAST to have this standard method answer useful info. This may be by using the individual existing methods that answer the correct string.

Step 2a:  Encourage third parties (tool vendors, goodie authors, o/s port maintainers) to implement that new standard method.

What does Joachim think we as a Community can do?

We cannot do much about Step 1 other than nagging Instantiations here and in support cases. Once Step 1 is made, we can do a lot about Step 2a: comb through our goodies and ported code and (re-)implement or error handling code.

Why does Joachim think this is of any use to anybody?

Because I can't believe I am the only person who is tired of writing lots of [:ex| ex isKindOf: ... ifTrue:[] ifFalse: []] cascades in handlers and still having lots of cases where the application simply says: "I know something went wrong but I won't tell you!"
Maybe many projects out there that have existed for 15 years or more have their own solutions for this kind of problem (one giant bloated block filled with ifTrue:s, but for new projects this is just another expensive hurdle that needs to be taken. A simple thing gets hard and tiresome in the existing code base.

Thanks for reading and commenting

Joachim


Am Dienstag, 25. Oktober 2011 22:28:40 UTC+2 schrieb [hidden email]:

I think I came up with this topic before - either here or on my blog.

What do people do to display a proper error message? Whatever method I try to use to extract user-readable info from exceptions and signals, there are always cases in which the error message will be useless nonsense like "An exception has occured" rather than the actual error message. 

It seems there is no unified method to access the error message of Exceptions that are wrapped in a Signal end such. I've skimmed through some customers' code as well and it seems everybody seems to break themselves a few dozen legs on their way to the info they want to display. Lots of isKindOf: and such, but nobody seems to have a real solution.

So is there a message common to all exceptions and signals that will allow me to display an error message? And if not, why not put in on the todo-list for V8.51?

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/-/aqUmeKSF0YgJ.
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.

So I'm back to my own thread. And I want to add a few more details to what I am talking about.

Part of my frustration comes from the fact that VAST not only uses Exceptions, but also AbtError objects, like AbtConverterError. These are incompatible to Exceptions, but are being used as such. Maybe (I haven't experimented with it and don't really have the time to do so) it would be sufficient to add a few methods like #description and #messageText to AbtError and its subclasses.

Then there is Glorp. The VAST port does a few strange things to overcome the fact that obviously in VAST 8.0 there was no #messageText in VAST's Exception class. The things it does are really incompatible with how Exceptions work. I've contacted Bob about this, because he seems to be working on a current port. Maybe this one can be solved.

It seems that using #description would work across Signals and most Exception classes of VAST. But still I remember seeing cases where the messages were useless (alon the lines of "An Exception has occured"). This may date back to the times when VAST supported both class based and instance based Exception handling and is possibly better today.

I am not talking about places like #isCfsError and such, because these don't throw exceptions at all and should be changed completely anyways. But this is probably a lot more work and risk than anybody is ready to take right now. So I guess we shouldn't be discussing them now. We'd probably all agree on both the fact that it's bad style and not a good place to start opening a construction site on now.
 
The whole situation is somewhat handle-able in a development environment, where a skilled developer will find the cause of a problem in a debugger in deterministic time, but when it comes to a deployed application where there is only a walback log and some popup dialog or message on a web page, there must be a way to show accurate and helpful (for the person who has to fix the problem at least) information.

So I've mentioned the methods #messageText and #description, but there also is #tag. Which one is the best / official way to store and retrieve error information? To me it seems, but I am not completely sure, that #description is the method to use.

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/-/2khcqCWFbNkJ.
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.