2009/3/24 Vaidotas Didžbalis <vaidasd at gmail.com>

> > And if I recall correctly the ANSI standard specifies that behaviour is
> > undefined when resuming a non-resumable Exception (!) so in some cases
> you
> > can do that too! :)
> No, you can not. IllegalResumeAttempt is signalled in that case, the
> only case I am aware of is pressing debugger's proceed button which is
> a bug I suggest.
>

Ok, it looks like I was remembering wrong. There are some weird things in
there that are undefined but it says it is "erroneous to send the message
[#resume:] if the receiver is not resumable".

Hitting Proceed in the debugger does not resume the exception, of course, it
unwinds to and resumes the suspended context. The bug in the debugger, as
far as I'm concerned, is that if you hit Proceed as soon as the debugger
pops up, it will resume the context that actually opened the Debugger (and
continue executing through all the exception handling code) rather than
resuming the context where the error was signaled.

> And do anyone share my opinion on coding style?

Well, if you are signaling an Exception it either needs to be non-resumable
or the code written so that it can continue with the resumed value. In the
code you are discussing, the block seems to combine a guard clause with
signaling an error. That is, no matter what "self error:" does, the rest of
the method should not be run because boolean is false. Since you don't post
the actual code, I can't be sure, though.

The question of style is thus, as far as I'm concerned, simply "should
senders of #error: assume that this method call will never return?". There
are two things that lead me to believe they should *not* make this
assumption:
 + we know the Debugger can cause the method to continue executing (and I
don't think that is a bug)
 + the ANSI spec says that the default implementation of #error: is to raise
an Error but that "conforming protocols may refine this message to perform
some [other] action" and that the return value is UNSPECIFIED.

So, in particular if you are writing cross-implementation portable code, I
think you are safer to assume that #error: *could* return.

My style issue here is that I think you should define your own error
subclasses rather than using #error:. At very least you should have a single
subclass you use for your package so that users can handle your errors
specially. Obviously having more meaningful subclasses for each kind of
error is even better.

Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090324/e3add694/attachment.htm