[squeak-dev] [Ann] System-PasswordManager
Locked
 
|
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 <[hidden email]> wrote: > > I have published MCPasswordManager as a separate package > > http://www.squeaksource.com/mc/System-PasswordManager > > Keith > > > |
Re: [squeak-dev] [Ann] System-PasswordManager
|
|
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. -- http://gulik.pbwiki.com/ |
Re: [squeak-dev] [Ann] System-PasswordManager
|
|
On Mon, Mar 23, 2009 at 9:00 PM, Michael van der Gulik <[hidden email]> wrote:
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 |
|
|
In reply to this post by Michael van der Gulik-2
> 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 |
|
|
In reply to this post by Julian Fitzell-2
> 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 |
Re: [squeak-dev] [Ann] System-PasswordManager
|
|
In reply to this post by vaidasd
2009/3/24 Vaidotas Didžbalis <[hidden email]>:
>> 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 > > -- Best regards, Igor Stasenko AKA sig. |
|
|
On Tue, Mar 24, 2009 at 12:39 PM, Igor Stasenko <[hidden email]> 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 |
Re: [squeak-dev] [Ann] System-PasswordManager
|
|
In reply to this post by vaidasd
2009/3/24 Vaidotas Didžbalis <[hidden email]>
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. 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 <[hidden email]> wrote: > 2009/3/24 Vaidotas Didžbalis <[hidden email]> >> >> > 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 > > > > |
Re: [squeak-dev] [Ann] System-PasswordManager
|
|
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 <[hidden email]> Julian, |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |