Dear VAST users,

I'd like to hear opinions of VAST users as well as Instantiations about something I've been developing deep disgust for over the years ;-).

I really hate the prefix "(ExError) An error has occured.:' in a Signal's #description.

And here is why I hate it with real passion:

• First of all, it is orthographcally inccorect. There is no point in having a full stop right befora a colon. But this is just for warming you up ;-)
  
• What's much worse: if you display the error string to an end user, it is completely useless. An end user has no idea what ExError or anything might mean, and when they start reading this sentence to you on the phone you lose time and have to motivate poeple to read on
• It is an NLS message (MxKRN15), so you could, in theory, replace it with a translated String. If you use the NLS feature. The idea that non-english software uses the NLS feature is a neat and good one, but hopelessly wrong. Like it or not. The translated String, however, wouldn't make much mroe sense
  
• It is not configurable or opt-out-enabled. You will always get this prefix added to your Exception's #description
• This is especially bad if you use proper error handling for forwarding exceptions with added context info, like in
  

[

 someCodeThatThrowsAnExceptionLikeThis: [Error signal: 'This is not a good idea'].

] on: Error

 do: [:ex| System message: 'Could not do this. Reason: ', ex description].

This will output something like

'Could not do this. Reason: (ExError) an Error has occured.: This is not a good idea'.

In my German case things are even worse becase the text will be in two languages like this:

'Das hat nicht funktioniert. Grund: (ExError) an Error has occured.:Das ist keine gute Idee'

You see, this is just plain nonsense and lots of unnecessary text. At least I think it is. 

So I wonder: does anybody see value in this Prefix text? Are there projects out there who actually use that textual information? I think whatever this may transport should better be done by asking the Exception questions like #isError or #isWarning or maybe even #isKindOf: but who the heck needs this text?

Or have I been missing a way to get rid of it by configuration for years now?

Should I not be using #description for displaying exceptions to end users? In my experience, neither #tag nor #messageText work for all kinds of Exceptions/ExceptionalEvents...

Do you need this textual information in your Application?

Does it help you in Debugging or when you read Walkback logs? (Of course the class/kind of exception could be printed there nicely, I am not saying I don't care what kind of Exception is thrown)

It is quite easy to get rid of this by changing Signal>>#description to (note the comment in the last line:

description
    "Synopsis:
        Return a textual description of the exception that was raised.

     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.
       
        To get the fixed description string for an ExceptionalEvent, send 'self exception description'.
    "
       
    | desc |
   
    desc := self exception description.

    ^ self messageText
        ifNil: [ desc ]
        ifNotNil: [ :mt | "desc, ': '," mt ]    "$NON-NLS$"

Is there anything that should keep Instantiations from incorporating this change (given they'd be willing to)? Do you see drawbacks of this change that I am not seeing?

I look forward to your comments

Joachim

So no other opinions on this prefix in textual Error descriptions?

Julian,

you are of course correct. You should always handle exceptions and it's best not to have any exception bubble up to the user. However, being a junior, I miserably fail on that front... ;-)

In many cases, I bet chances are you'd sometimes wish to see the "real" exception rather than some home-made: "Something went wrong, but I forgot what, because my programmer didn't think of that Exception, which I forgot".

Oh, and btw. Even VAST is not built that way. If you use an AbtConverter in a CE GUI, there is no mechanism (other than NLS) to handle converter errors and replace it with something better.... And there you get these darn "(ExError) An Error has Occured.:" messages, which have zero calories and no other nutrients.

Joachim

Am Mittwoch, 8. Mai 2019 17:04:46 UTC+2 schrieb Julian Ford:

Well...to be quite honest, Joachim, and with all due respect...

my opinion is that it is the developer who should handle these messages, and not the Tool vendor.

My application has been around for 13 years, and is in over 260 offices, but never once has anyone

seen the ExError message.  I always make sure to handle all exceptions with appropriate user-friendly

messages.

If an exception reaches the user like this, it means the developer has failed to handle it.

Like I said, though....it is just my opinion....

Regards,

Julian

On Monday, May 6, 2019 at 2:28:12 AM UTC-4, [hidden email] wrote:

So no other opinions on this prefix in textual Error descriptions?

Oh, and the short answer is: yes, I'd like to see this issue addressed, but am not sure if it might intrdouce troubles....

Am Freitag, 10. Mai 2019 07:54:31 UTC+2 schrieb Joachim Tuchel:

Seth,

I wanted to hear opinions before I send in a support request, not only but also because I sometimes am too fast sending them in and thus waste your time.

I am quite sure VAST users have a lot of respect for and value your consideration of stability and backwards compatibility. The smooth change to 64 bits and a completely new VM within 2 releases were a lighthouse example, imo. After all, this is part of why VAST has been in use at organizations for decades and still is and will be. So it is absolutely my intention to learn about ideas to why my idea for a change might be a bad one before I ask you at Instantiations to  take action.

I have the feeling the number of opinions expressed here either means nobody cares (which would mean it really won't hurt) or there is too much of a chance that some poeple who might be interested in this are not listening to this forum. So I am not sure you should do anything at this time.

In my experience from a number of projects in VAST, there are way too little people who understand exception handling in Smalltalk, not to speak of how how many people feel overwhelmed by number of different mechanims to be found in VAST (isXXXError vs. integer return codes vs. INstance based exceptions vs. Class based/ANSI exceptions). This is why I thought it is better to understand if people rely on this prefix.

Joachim

Am Donnerstag, 9. Mai 2019 16:32:13 UTC+2 schrieb Seth Berman:

Hello Joachim,

We hear you and thanks for the suggestion.

Since this is a community forum and not everyone from Instantiations comes here, my suggestion is once you feel you have a valid proposal for a change...please send this to [hidden email].  That way it goes into our tracking system which then becomes a line item we discuss in weekly meetings.  If it's here...it may or may not turn into anything. Turning all proposals for change here into some sort of action item for the company is just not what this forum was intended to be used for.  I only say this because I don't want you to feel ignored, either.

"...I am pretty sure it doesn't hurt anyone."

- Yeah, well you could be right. I'm just having to internally chuckle at the number of times I've said this with the product, and then had to turn around and undo the change.  And supporting all versions of the product till the end of time is fun because you get to readdress your mistakes for years into the future with support cases as customers slowly migrate up version levels. The accumulated cost of this for the company is something I hate to think about.

However, I understand that us engineers are the eternal optimists:) 

To wrap up, would you like me to put a support case in for you regarding this?

- Seth

On Thursday, May 9, 2019 at 9:54:40 AM UTC-4, Joachim Tuchel wrote:

Julian,

I would like to be that over-paranoid about Exceptions but sometimes they just jump out of nowhere. Maybe I still haven't stuck my feet into enough bear traps ;-) I only started programming less than 4 decades ago, so still a lot to learn.

But fun aside, errors occur and chances are you don't think of all the possible problems in the first place. (In my case, "chances are" is very euphemistic). In such events, you need information. Something that helps understand a problem and find possible causes. "(ExError) An Error has occurred.:" is a lot of text to read befor you get to the real thing. If your server sends you mails with a subject line from the exception, all the real estate on my mobile is wasted with this overture. If a user reads an error message to you on the phone, you've starved before they reach the unnecessary fullstop in this expression. Now imagine a non-native english speaker reading this text to you...

I guess you get the message. I. do. NOT. like. this. text.

And I'd like to convince Instantiations to remove it. The fix is in this thread, and I am pretty sure it doesn't hurt anyone.

 

Joachim

Am Donnerstag, 9. Mai 2019 15:31:09 UTC+2 schrieb Julian Ford:

LOL....I do agree about the lack of beneficial sustenance!

I'm actually quite over-paranoid about error messages...something I inherited from my days working

under a VERY strict programmer analyst at IBM a hundred years ago.

I likely spend more time than I should checking results from messages, and explicitly posting error messages

to users.

More often that not, I try to catch an error BEFORE there is an exception.

That way I have complete control over what happens.

This is obviously much more work than simply wrapping code with an #on:do:,

but just the way my own ST development style evolved.

That said, I am not suggesting there is anything at all wrong with having a nicer Exception message.

I just wanted to through in my $0.02, and let you know you were not being ignored....lol.

Julian

On Thursday, May 9, 2019 at 1:36:47 AM UTC-4, Joachim Tuchel wrote:

Julian,

you are of course correct. You should always handle exceptions and it's best not to have any exception bubble up to the user. However, being a junior, I miserably fail on that front... ;-)

In many cases, I bet chances are you'd sometimes wish to see the "real" exception rather than some home-made: "Something went wrong, but I forgot what, because my programmer didn't think of that Exception, which I forgot".

Oh, and btw. Even VAST is not built that way. If you use an AbtConverter in a CE GUI, there is no mechanism (other than NLS) to handle converter errors and replace it with something better.... And there you get these darn "(ExError) An Error has Occured.:" messages, which have zero calories and no other nutrients.

Joachim

Am Mittwoch, 8. Mai 2019 17:04:46 UTC+2 schrieb Julian Ford:

Well...to be quite honest, Joachim, and with all due respect...

my opinion is that it is the developer who should handle these messages, and not the Tool vendor.

My application has been around for 13 years, and is in over 260 offices, but never once has anyone

seen the ExError message.  I always make sure to handle all exceptions with appropriate user-friendly

messages.

If an exception reaches the user like this, it means the developer has failed to handle it.

Like I said, though....it is just my opinion....

Regards,

Julian

On Monday, May 6, 2019 at 2:28:12 AM UTC-4, [hidden email] wrote:

So no other opinions on this prefix in textual Error descriptions?

Hi Seth,

thank you very much for letting us understand how you feel and think about changes and what is needed to be sure a change is not only worth it but also the right thing to do.

As I said before, VAST is what it is because this way of working with change leads to great stability, with all its consequences, some of which we might not like. The whole point of my post here was to help me understand if asking you for starting the thought process is worth it. I know my way around it with a simple comment that can be re-appliad with every new version (I've been doing so for a while now) and if you come to the conclusion there is too much of a risk or too little gain in it, that is okay with me.

Maybe someone else wants to comment on why they might face problems if the prefix would be gone. Using your example, an asbsent log entry has the potential to be fatal, of course. That is why I explicitly asked if anybody here is relying on this text.

Have a nice weekend.

Joachim

Hi Joachim,

Thanks for your great thoughts as always.

A nice weekend to you and the family

- Seth

On Friday, May 10, 2019 at 7:52:37 AM UTC-4, Joachim Tuchel wrote:

Hi Seth,

thank you very much for letting us understand how you feel and think about changes and what is needed to be sure a change is not only worth it but also the right thing to do.

As I said before, VAST is what it is because this way of working with change leads to great stability, with all its consequences, some of which we might not like. The whole point of my post here was to help me understand if asking you for starting the thought process is worth it. I know my way around it with a simple comment that can be re-appliad with every new version (I've been doing so for a while now) and if you come to the conclusion there is too much of a risk or too little gain in it, that is okay with me.

Maybe someone else wants to comment on why they might face problems if the prefix would be gone. Using your example, an asbsent log entry has the potential to be fatal, of course. That is why I explicitly asked if anybody here is relying on this text.

Have a nice weekend.

Joachim

Hi Seth,

Is it possible/worthwhile to add a global switch that would allow a developer to choose between the "old" messages and a "new" set of messages?  I know this would add to the complexity of the change, hopefully the code change would be "simple" and "easy" to be sure is correct.  It would then allow developers who are dependent upon the current text to keep their code as is.

Lou

On Friday, May 10, 2019 at 8:12:04 AM UTC-4, Seth Berman wrote:

Hi Joachim,

Thanks for your great thoughts as always.

A nice weekend to you and the family

- Seth

On Friday, May 10, 2019 at 7:52:37 AM UTC-4, Joachim Tuchel wrote:

Hi Seth,

thank you very much for letting us understand how you feel and think about changes and what is needed to be sure a change is not only worth it but also the right thing to do.

As I said before, VAST is what it is because this way of working with change leads to great stability, with all its consequences, some of which we might not like. The whole point of my post here was to help me understand if asking you for starting the thought process is worth it. I know my way around it with a simple comment that can be re-appliad with every new version (I've been doing so for a while now) and if you come to the conclusion there is too much of a risk or too little gain in it, that is okay with me.

Maybe someone else wants to comment on why they might face problems if the prefix would be gone. Using your example, an asbsent log entry has the potential to be fatal, of course. That is why I explicitly asked if anybody here is relying on this text.

Have a nice weekend.

Joachim

Hi Joachim,

Here is a real world example of why we are very reluctant to change base code.

In 2015 we had a customer complain the method DateAndTime>>printMilliseconds:on: was not printing all three digits of the milliseconds value if the trailing digits were zero.

For instance, they wanted 2019-05-10T15:22:07.4 to print as 2019-05-10T15:22:07.400. Seems reasonable and pretty trivial, right?

We looked at the ANSI spec and it was ambiguous on this subject.

Then John pointed out that we might very well have customers who have code that relies on this non-printing of the trailing zeros. We had no way of knowing.

So in the end we decided to leave this method alone.

Regards,

Donald [|]

On Friday, May 10, 2019 at 7:52:37 AM UTC-4, Joachim Tuchel wrote:

Hi Seth,

thank you very much for letting us understand how you feel and think about changes and what is needed to be sure a change is not only worth it but also the right thing to do.

As I said before, VAST is what it is because this way of working with change leads to great stability, with all its consequences, some of which we might not like. The whole point of my post here was to help me understand if asking you for starting the thought process is worth it. I know my way around it with a simple comment that can be re-appliad with every new version (I've been doing so for a while now) and if you come to the conclusion there is too much of a risk or too little gain in it, that is okay with me.

Maybe someone else wants to comment on why they might face problems if the prefix would be gone. Using your example, an asbsent log entry has the potential to be fatal, of course. That is why I explicitly asked if anybody here is relying on this text.

Have a nice weekend.

Joachim

As the guilty party in the 'isNil ifTrue: []' -> 'ifNil: []' debacle, I can attest to the laws of unintended, and unexpected, consequences.

An additional consideration, particularly in regard to exception handling, is that there is a considerable amount of product code that depends on the existing behavior. This means that the change can roll through a lot of other code changes with their own risks.

And then there is the previously mentioned undiscovered consequences in infrequently visited, but important, addons like the WidgetKit products (we have forgotten more than once over the years to audit one or more of these products for the effect of changes).

And lastly, but certainly not finally, there are the subtle differences between platform behaviors. While Windows and Linux get a really good workout simply because we use them every day in development, the same cannot be said for Solaris and AIX.

Like Seth, I learned over the years to keep my hands in my pockets rather than on the keyboard when considering changes.

John