[squeak-dev] Problems with #caseError

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Feb 22 17:37:48 UTC 2020


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<http://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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200222/04123728/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fix caseError.1.cs
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200222/04123728/attachment.ksh>


More information about the Squeak-dev mailing list