I have published MCPasswordManager as a separate package
http://www.squeaksource.com/mc/System-PasswordManager
Keith
Thank you, I have question about style: in the code I see:
boolean ifFalse:[^self error: 'Some error'].
sould'nt it be like this:
boolean ifFalse:[self error: 'Some error'].
Since “self error:" is definitely expected to signal exception?
On Sun, Mar 22, 2009 at 11:26 PM, Keith Hodges keith_hodges@yahoo.co.uk wrote:
I have published MCPasswordManager as a separate package
http://www.squeaksource.com/mc/System-PasswordManager
Keith
On Sun, Mar 22, 2009 at 11:26 PM, Keith Hodges keith_hodges@yahoo.co.uk wrote:
I have published MCPasswordManager as a separate package
http://www.squeaksource.com/mc/System-PasswordManager
Keith
2009/3/24 Vaidotas Didžbalis vaidasd@gmail.com Thank you, I have question about style: in the code I see:
boolean ifFalse:[^self error: 'Some error'].
sould'nt it be like this:
boolean ifFalse:[self error: 'Some error'].
Since “self error:" is definitely expected to signal exception?
You can validly continue execution from an error (unlike, for example, Java). Sometimes, I'd get an error, fix things up in the debugger and then continue execution.
Gulik.
On Mon, Mar 23, 2009 at 9:00 PM, Michael van der Gulik mikevdg@gmail.comwrote:
2009/3/24 Vaidotas Didžbalis vaidasd@gmail.com
Thank you, I have question about style: in the code I see:
boolean ifFalse:[^self error: 'Some error'].
sould'nt it be like this:
boolean ifFalse:[self error: 'Some error'].
Since “self error:" is definitely expected to signal exception?
You can validly continue execution from an error (unlike, for example, Java). Sometimes, I'd get an error, fix things up in the debugger and then continue execution.
Yes, Vaidotas, take a look at Exception>>isResumable. It's overridden on Error to return false but can be overridden again by subclasses.
As long as an Exception is resumable, you can do the following:
[self doSomething] on: SomeError do: [ :error | error resume: 5 ]
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! :)
Julian
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.
And if I recall correctly the ANSI standard specifies that behaviour is undefined when resuming a non-resumable Exception (!)
If it is true, then we can simply put that standard does not cover this topic at all.
regards, Vaidotas
2009/3/24 Vaidotas Didžbalis vaidasd@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
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@gmail.com wrote:
2009/3/24 Vaidotas Didžbalis vaidasd@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
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@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@gmail.com wrote:
2009/3/24 Vaidotas Didžbalis vaidasd@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
You can validly continue execution from an error (unlike, for example, Java). Sometimes, I'd get an error, fix things up in the debugger and then continue execution.
New image has only one implementation of "error:", and it signals non-resumable exception. This contradicts to the behaviour of debugger, since pressing Proceed in debugger resumes non-resumable exception. So it a bug in Debugger. Regarding coding style, if function called do returns some value, then it must have some meaning to the caller. I fail to see the meaning of receiving non-resumable exception as a result of function call. I think the right way to look at this is to assume, that after signaling non resumable exception none of the following method instructions will be executed; so caller must not bother checking the result of function. Vaidotas
2009/3/24 Vaidotas Didžbalis vaidasd@gmail.com:
You can validly continue execution from an error (unlike, for example, Java). Sometimes, I'd get an error, fix things up in the debugger and then continue execution.
New image has only one implementation of "error:", and it signals non-resumable exception. This contradicts to the behaviour of debugger, since pressing Proceed in debugger resumes non-resumable exception. So it a bug in Debugger. Regarding coding style, if function called do returns some value, then it must have some meaning to the caller. I fail to see the meaning of receiving non-resumable exception as a result of function call.
It is because, in debugger you can manually force to return from a context with some value, which you can enter. Sometimes, if error is not critical, one could decide to continue running the process w/o stopping it.
I think the right way to look at this is to assume, that after signaling non resumable exception none of the following method instructions will be executed; so caller must not bother checking the result of function. Vaidotas
On Tue, Mar 24, 2009 at 12:39 PM, Igor Stasenko siguctua@gmail.com wrote: ...
It is because, in debugger you can manually force to return from a context with some value, which you can enter. Sometimes, if error is not critical, one could decide to continue running the process w/o stopping it.
Maybe it is ok for debugger allowind developer to resume non resumable exception; interaction with debugger is part of development process, not the process of end user using a system.
And do anyone share my opinion on coding style?
Regards, Vaidotas
squeak-dev@lists.squeakfoundation.org