[Pharo-project] Another finalization concern: error handling

Henrik Johansen henrik.s.johansen at veloxit.no
Tue Oct 12 07:25:57 EDT 2010


On Oct 11, 2010, at 10:17 18PM, Igor Stasenko wrote:

> 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).
> 

I agree it should be the executor doing handling.
However, if you get to this point, the executor already had the chance to do so in the finalize method itself, so I don't really see the point of sending it back..

Personally, I feel the only promises FinalizationRegistry should make wrt. to errors during finalization, is it should never lead to:
- termination of the (or a) finalization process, 
- discarding another finalization action.

IE I am perfectly fine with an error here being thrown in your face (hopefully in a somewhat debuggable way, unlike what happened in your first example when removing the error-swallowing), as you've already passed the point a correction should be made, and there's nothing more intelligible to do than making sure everything keeps working, and inform of the error.
(Pretty sure the error swallowing was a quick hack for keeping everything working in the first place ;) )

Cheers,
Henry



More information about the Pharo-dev mailing list