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
> 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
(Hit send to early, see below ...)
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"
method := Compiler newcompiledMethodFor: '#bar caseOf: {[#bar] -> [2]}'in: nil to: nil notifying: nil ifFail: nil.method allLiterals."--> #(#caseError #bar #caseOf:)"