Yeah, sure, I see your point.

I agree that (in general) when signaling a non-resumable Exception you
probably do not need to write code do deal with the Exception being resumed,
though there may be individual cases where doing so is as simple as or even
simpler than not.

But I think the big issue is what you believe your contract is with the
method (and what kind of code you are writing). If you implement your own
non-resumable Errors and signal them directly, you can be pretty certain
that the #signal method will not return. That, along with the other
benefits, makes that the right solution in my opinion.

Julian

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

> Julian,
>
> Ok, next try. The assumption that method call that sends "self
> myNotResumableError" will not return is valuable in my opinion, since
> it encourages simpler, more readable code, programmer does not need to
> care checking the return value in cases it makes no sense.
> Pressing Debugger's Proceed button is only the case where things may
> go wrong with this, but end users will never see debugger.
>
> Regards,
> Vaidotas
>
> On Tue, Mar 24, 2009 at 2:10 PM, Julian Fitzell <jfitzell at gmail.com>
> wrote:
> > 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/889b8826/attachment.htm