[Pharo-project] Another finalization concern: error handling

Schwab,Wilhelm K bschwab at anest.ufl.edu
Mon Oct 11 19:40:54 EDT 2010


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-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua at gmail.com]
Sent: Monday, October 11, 2010 6:35 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another finalization concern: error handling

On 12 October 2010 00:32, Schwab,Wilhelm K <bschwab at 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-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua at gmail.com]
> Sent: Monday, October 11, 2010 4:17 PM
> To: Pharo-project at 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 <bschwab at 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 at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




More information about the Pharo-dev mailing list