Sig, You seem to be doing a good job of this, so if you think I'm off, feel free to prove it. The executors (in Dolphin, the objects themselves) probably know more than the registry about how to handle errors, and (it seems to me) either generated them or could have readily caught them if there were something different to do based on the information.
Maybe the crux of the matter is as follows: are you thinking of an executor class with subclasses that implement #handleFinalizationError: (a hook), or is it more "this happened, thought you might like to know." I think I read it more as the latter, probably assuming that #finalize would retry if that could reasonably be expected to help. Bill ________________________________________ From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguc...@gmail.com] Sent: Monday, October 11, 2010 6:35 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 12 October 2010 00:32, Schwab,Wilhelm K <bsch...@anest.ufl.edu> wrote: > Sig, > > How hard it is or isn't is not nearly as important as your tackling it and > doing so with the right tools. So again I say, carry on :) > > On self vs. executor as the receiver of #handleFinalizationError:, I might > lean toward "self" as it will be closer to the system. There is probably > little the executor can do, and it either missed or raised the error in the > first place, right? I *think* the most you are going to to do is log that > something went wrong, but I could be missing something. > I'm not sure about that . >From other size, a finalizer could better know why error can occur and how to handle it graciously, if its possible, and not just showing 'you suck' at the center of screen ;) Because weak registry can tell even less about nature of error, because it propably knows nothing about its finalizers, except that they understand #finalize message. > #ensure: attempts to evaluate the argument block whenever the receiver of it > is completed (modulo some ominous sounding questions raised in the past > months to a year??). #ifCurtailed: should be similar, but evaluating the > argument/block only on abnormal (including, I think, ^) exit of the block. > > Does that help at all? > Yes. Thanks. I now remember semantics of it. Been there when dealt with Process>>terminate voodo. > Bill > > > ________________________________________ > From: pharo-project-boun...@lists.gforge.inria.fr > [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko > [siguc...@gmail.com] > Sent: Monday, October 11, 2010 4:17 PM > To: Pharo-project@lists.gforge.inria.fr; The general-purpose Squeak > developers list > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On 11 October 2010 22:49, Schwab,Wilhelm K <bsch...@anest.ufl.edu> wrote: >> Sig, >> >> The most important words in there are "critical section." Carry on :) >> > > Oh, please. This is not too hard to code. > > My mind rolling around following choice(s) (there may be others i don't see). > What would be a proper way to handle error during #finalize. > > [ executor finalize ] on: Error do: [:ex | > self handleFinalizationError: ex "where self is registry" > ]. > > or: > > [ executor finalize ] on: Error do: [:ex | > executor handleFinalizationError: ex > ]. > > > of course, i should catch this error in test, so i can verify that: > > a) test is get notified upon synthetically made error > b) no matter what i do inside error handler (up to 'Processor > activeProcess terminate'), a finalization process continues working > (or restarts without losing remainder of executors). > > > Also, i used #ensure: and #ifCurtailed: but i tend to forget where > they are applicable and how. > So, little help in this regard will be wellcome. > >> Bill >> > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
