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:] messageshttp://forum.world.st/Question-regarding-compilation-of-caseOf-otherwise-messages-td5112253.html. 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 squeak-dev-bounces@lists.squeakfoundation.org 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 squeak-dev-bounces@lists.squeakfoundation.org 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