[squeak-dev] Problems with #caseError

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Mon Feb 24 14:38:32 UTC 2020


Hi Marcel,


thanks for the summary. Of course, you're right, if we want to fix all bugs, we will never release Squeak again :D


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 24. Februar 2020 15:11:41
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Problems with #caseError

Hi Christoph,

both issues can be addresed after the 5.3 release. Those a no new issues and not that severe to justify pushing back the first release candidate even further away.

1) Regressions compared to Squeak 5.2 (or maybe 5.1) are problematic.
2) Debuggers popping up for frequent programming tasks are problematic.

Otherwise: There are loads of bugs still luring inside the environment. Many of them rarly surface and can be worked around with little effort. ;-) Those get usually addressed in the "alpha" stage.

Best,
Marcel

Am 22.02.2020 18:37:56 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:

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/20200224/ed2abdaa/attachment.html>


More information about the Squeak-dev mailing list