Exceptions' descriptions contain stupid prefix in VAST

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Exceptions' descriptions contain stupid prefix in VAST

jtuchel
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






--
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 https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

Louis LaBrunda
+1.

Lou

On Friday, April 26, 2019 at 5:59:40 AM UTC-4, [hidden email] wrote:
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






--
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 https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

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




--
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 https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

rjulianford
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?




--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/3a660862-0776-4882-87a9-a7da771d3c94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

jtuchel
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?




--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/f12afffe-bba7-455e-b74e-cd2ff8e512bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

rjulianford
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?




--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/bf9fa71e-f75b-4450-a668-8cd1c218616e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

jtuchel
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?




--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/617ca720-122e-4204-9724-d165aa47732e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

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?




--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/3670f0d4-0525-4500-ae27-84a723dea4c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

jtuchel
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="MdS548q5AgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">vast-s...@instantiations.com.  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?




--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/7740a755-40ac-4c01-9645-d6d87c4e2592%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

jtuchel
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?




--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/8d0397e3-50f8-48a7-a0d3-24e140f4527c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

Seth Berman
Hi Joachim,

Thanks for the compliment.  Maintaining stability in a system as mature as VAST while still pushing it aggressively forward is an undervalued (or perhaps unvocal) art in the industry, so I'll pass on the compliments to the team.

Good...sounds like we are on the same page.  I appreciate the thoughtful discussions you bring forth here.  My only concern was that Instantiations silence might be interpreted strictly as "Instantiations doesn't care" either from you or anyone following along waiting for us to respond.

If we don't respond, it could be that we simply don't know and have nothing useful to add, or the Instantiations staff that would have an opinion simply are not here to voice it.  Certainly never responding to anything would be kind of strange, but I think we respond to most topics, just not all of them.

Yes, I'm happy to put in the case for review.

I thought folks might appreciate some insight into the amount of energy that goes into evaluating even the most simple changes to the product and how seriously we take it.  I used to be an application developer, and while backwards compat was a concern, it was nothing compared to platform development of a mature system with no end-of-life on any versions.
After so many incidents of being burned by the unforeseeable, my general approach has been refined to the following when looking at changes like these.

First, we classify the change.  In this case, it's "base code".  The most perilous area of all.  When we see this internally at the company, our defensive mental shields raise to maximum:) . However, it's not quite "historical code", which is @1996 code.  Thats the worst of all to deal with.  This method was changed in recent times and I've tracked it back to Case 50663 which is based on your discussion with John to change Signal>>description (https://groups.google.com/forum/#!topic/va-smalltalk/Fs6trFTfTs0).  So here we are again:)

Next, we assume the change breaks something. Because this class of change usually does, if not now, then some years in the future as part of a customer migration from a team that no longer has the knowledge from the original team that built it a decade before and did something unforeseeable.  The good news here is it was already changed once before in recent times and I don't recall huge fallout.

Then, we classify the breakage from the change.  Since we assume it's going to break somebody, we need to understand both how the break occurs and how detectable that break will be (i.e. locality of the error to the change). In this case, we have a textual change, it's not localized to the method (i.e. that change is returned from the method and propagates elsewhere), and it's a public method.
Public methods mean automatic migration guide entries when changing args or return values.  Naturally, we like to keep these to a minimum.  But zero migration isn't realistic, so we obviously have to do it.  But it adds more risk, even company perception risk because we have commitments for public methods and the more the contracts change to those, the less companies will be amenable to migrate. Likewise, its more expensive for us to support customers on older versions of the product. Private methods are for us, we will change them at will and with no notification...but that doesn't make it automatically safe.
A textual non-localized change means the probable breakage points are going to be with customer code that is parsing the result of Signal>>description to make a decision.  The code may have a stream that indexes up to the ':' because they know whats next is mt, but now ':' won't be there with this change. The detectability of this change is not classifiable.  It may be detected immediately or never.  For example, if a logger is making a decision to log exceptions with certain descriptions and has the parsing logic I describe above, then nothing breaks...the logging statements will simply be absent. This may go unnoticed now, years, or never.

So finally, I take this pessimistic view of the world and roll it all up to help answer one simple question..."Is it worth it?"
Sometimes it is because not doing it would hold us back from moving the product forward.
Sometimes it is because the localization of the change is so high that it can't be conceived how it would break unless someone was doing really tricky code like looking into the compiled method or stack frame itself (yes...we have jaw-dropping examples of this from IBM base code).
Sometimes it is because the detectability is so high that we are willing to do a migration entry and know that even if folks didn't read the migration guide, they are going to have no other option but address this and see that it has changed.  (obviously we assume the change itself was worth doing).
Sometimes it is because the code itself has a short history and is well understood by the current team enough to handle the change.
Sometimes it is because the area of change is in some obscure higher-layer corner of the codebase whose impact in any direction would likely be minimal.

All this to say, even small changes can require a lot of thought and time on our end.
Now scale this up to changes like "New UI Frameworks", "Unicode", "Virtual Machine", and you can start to see why these take years. And if it were any other way, we wouldn't have the product we have...we would have a product that breaks constantly or a product with a whole host of frameworks that we say we are unwilling to support any longer and rip them out of the product.  There is one of those "Pick 2" Triangle diagrams with the labels Fast Delivery, Cheap and Stable somewhere in here:)

My statements may indicate that we won't do this.  But, that hasn't been decided since we have not performed the mental exercise yet.  The strongest point in favor is that it has changed in recent times.  The points I don't like is that it's in base code, public and textual change that is not localized to the method.
But, it will be considered for sure.

- Seth

On Friday, May 10, 2019 at 1:55:52 AM UTC-4, Joachim Tuchel wrote:
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?




--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/f8d49281-e002-4187-9f0c-7f8526bb63d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

jtuchel
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

--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/9a2780e4-578e-4fef-9875-615098af7a33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

Seth Berman
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

--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/94103f74-56fa-4cd7-8d34-44715945c58e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

Louis LaBrunda
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

--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/df62d487-53d6-4fa4-90e5-e673574f0076%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

Seth Berman
Hi Lou,

An intriguing suggestion, but I would prefer not to go down this path.
First, when getting support cases, now we'll have to know to ask which "message set" they have chosen..new or old.  Of course, we'll forget to do that and think about it about 5 exchanges later.
Second, customers will modify it so it will be a mixture of new and old behavior for some.  We'll never be sure of anything again.
Third, yes...more complexity...more work for us to do to manage this over time.
Finally, statistically the breakage comes from teams who have no idea they are dependent on the current code (i.e. current team / historical codebase)..so this doesn't really solve the issue.

But I appreciate the thinking outside the box approach...thanks Lou

- Seth

On Friday, May 10, 2019 at 9:09:10 AM UTC-4, Louis LaBrunda wrote:
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

--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/91b045be-e967-4bed-b76a-f08ae93561c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

dmacq
In reply to this post by jtuchel
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

--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/aaacfaf7-eec5-4170-a7d1-732d9274ca55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

Richard Sargent
Administrator
In reply to this post by jtuchel
On Friday, May 10, 2019 at 4:52:37 AM UTC-7, 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.

Joachim,

I recently went through an exercise in GBS to use #messageText for getting information from exceptions. What happens if you change from "ex description" to "ex messageText" in your example?




Have a nice weekend.

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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/248b6023-ac6c-48d4-88dc-439399c6fb6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

Seth Berman
In reply to this post by dmacq
Hi All,

I've got an even a more fun example to share.
There was once a change to EsImageStartUp class>> #outputWalkback:on:process: that had a change from 'isNil ifTrue: []' to 'ifNil: []'.
Seems pretty straightforward right?  Well, turns out that 'isNil ifTrue: []' is a series of optimized message sends that are inlined and 'ifNil: []' actually creates a new stack frame.  Because of this, the walkback code that assumes stack frame layout broke and caused another walkback...which caused another walkback..which caused another walkback.....and the support cases rolled in ($$$).
After this (and a few dozen others), my view of the world has changed considerably

- Seth

On Friday, May 10, 2019 at 3:29:07 PM UTC-4, Donald MacQueen wrote:
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

--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/11680b2c-6c3b-4d84-905d-c36d0923544d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

John O'Keefe-3
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

--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/c9bdc743-5a51-4152-a49c-37f580af9b7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Exceptions' descriptions contain stupid prefix in VAST

Seth Berman
Great insight John,

The great part about the 'isNil ifTrue: []' -> 'ifNil:[]' is the completely ridiculous set of consequences to such a benign and expected action.
Kind of like making a trip to the local supermarket whose entrance is wired with explosives. No one can really call you guilty for opening the door.
The point of the story is now when someone asks us to go to the supermarket for them, we kinda expect its wired with explosives and we just like to make very sure what we're being asked to get is really really compelling:)

- Seth

On Sunday, May 12, 2019 at 6:38:54 AM UTC-4, John O'Keefe wrote:
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

--
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 https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/587e706e-db74-47df-ba36-2dcdd4c1d869%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
12