2009/3/24 Vaidotas Didžbalis <span dir="ltr"><<a href="mailto:vaidasd@gmail.com">vaidasd@gmail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">> And if I recall correctly the ANSI standard specifies that behaviour is<br>
> undefined when resuming a non-resumable Exception (!) so in some cases you<br>
> can do that too! :)<br>
</div>No, you can not. IllegalResumeAttempt is signalled in that case, the<br>
only case I am aware of is pressing debugger's proceed button which is<br>
a bug I suggest.<br><div class="im"></div></blockquote><div><br>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".<br>
<br>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.<br>
</div>> And do anyone share my opinion on coding style?<br><br>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.<br>
<br>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:<br>
+ we know the Debugger can cause the method to continue executing (and I don't think that is a bug)<br> + 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.<br>
<br>So, in particular if you are writing cross-implementation portable code, I think you are safer to assume that #error: *could* return.<br><br>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.<br>
<br>Julian<br></div>