Problems with #caseError

(Hit send to early, see below ...)

> Otherwise, I don't see any reason to print out the receiver. We could also name it #caseError: anObject and print out this object

I have the feeling that this one would actually be more convenient because the error would be raised on the "failing" object. (Vividly speaking: The unrecognized object is not guilty of being unrecognized, but rather the selecting object is guilty of not recognizing the object.) But this might be a highly opinion-based discussion. On the other hand, #errorNonIntegerIndex belongs to the same category. Supporting the first argument again, #errorSubscriptBounds: is implemented on the calling receiver class ... Really not sure about this.

However, please note that a parametrized #caseError: would require something like

thisContext sender receiver caseError: self

Am 22.02.2020 18:37:56 schrieb Thiede, Christoph <[hidden email]>:

Here is a changeset that fixes the #caseError issue in a conservative way (no #caseError: with argument).

Unless we decide to parametrize #caseError, I think this one would be small enough for 5.3. Please review.

Please see also Question regarding compilation of #caseOf:[otherwise:] messages. I did not touch the relevant lines in this fix, but as I do not understand their function at the moment, I cannot rule out that they would also need to be adapted.

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Samstag, 22. Februar 2020 17:35:11
An: Squeak Dev
Betreff: Re: [squeak-dev] Problems with #caseError

 

> Otherwise, I don't see any reason to print out the receiver. We could also name it #caseError: anObject and print out this object

I have the feeling that this one would actually be more convenient because the error would be raised on the "failing" object. (Vividly speaking: The unrecognized object is not guilty of being unrecognized, but rather the selecting object is guilty of not recognizing the object.) But this might be a highly opinion-based discussion. On the other hand, #errorNonIntegerIndex belongs to the same category. Supporting the first argument again, #errorSubscriptBounds: is implemented on the calling receiver class ... Really not sure about this.

However, please note that a parametrized #caseError: would require something like

thisContext sender receiver caseError: self

in the non-inlined (we probably have a better term for this?) version of #caseOf:otherwise:. Would this be a code smell?

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Dienstag, 18. Februar 2020 16:23:50
An: Squeak Dev
Betreff: Re: [squeak-dev] Problems with #caseError

 

(Hit send to early, see below ...)

---

Von: Thiede, Christoph
Gesendet: Dienstag, 18. Februar 2020 16:21 Uhr
An: Squeak Dev
Betreff: Problems with #caseError

 

Hi all,

there are two problems with #caseError.

First one:

Given the following example, you will receive a confusing error message:

#foo caseOf: {[#bar] -> [2]. [#baz] -> [3]} 

"--> Error: Case not found (nil), and no otherwise clause"

Either #caseError should be called on #foo, then this would be compiler bug.

Otherwise, I don't see any reason to print out the receiver. We could also name it #caseError: anObject and print out this object, but the current message is not helpful IMO ...

Second one:

I'm not sure whether it is expected behavior how #allLiterals works on the following example:

method := Compiler new

compiledMethodFor: '#bar caseOf: {[#bar] -> [2]}'

in: nil to: nil notifying: nil ifFail: nil.

method allLiterals.

"-->  #(#caseError #bar #caseOf:)"

This can be confusing when searching for all users of #caseError. Should we handle this edge case in #allLiterals?

Best,

Christoph

Hi Dave,

I am sorry for the confusion. It took me some time to finally find the right thread, but apparently, Nicolas already has merged this changeset last May via Compiler-nice.430. (Thank you, Nicolas!) Because the thread when I mentioned it here ended with Marcel's advice to merge the changeset later, I had assumed that it would still be to do.

I could now, once again, point to the advantages of a GitHub-like issue and PR tracker where you could close and auto-reference threads from each other, but I guess I have already done this often enough. :-) Maybe it would be a good idea to (manually) send a short confirmation message directly to the thread where a changeset has been posted when someone finds the time to merge it. For inbox versions, this process is easier because they are arranged in Monticello with a clear identifier ...

Again, sorry for wasting your time! Nevertheless, your thoughts on #caseError: (with argument) and my #allLiterals observation are highly welcome. :-)

> I should note that it took me quite some time to figure out the context of this message.

I have no clue why the Nabble link does not point to the exact conversation. Usually, it does as far as I know. I also think it would be an improvement if replies that are sent via Nabble would have attached the entire conversation. Are we in control of the Nabble sources to make such a change?

Best,

Christoph