[squeak-dev] Problems with #caseError

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Feb 22 16:35:11 UTC 2020


> 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/0f01d15c/attachment.html>


More information about the Squeak-dev mailing list