Hi Karen, On 07/17/10 01:30 AM, Karen Tung wrote: > During the implementation of the engine, we found a problem > with using errsvc. > > Background: > ------------------------ > - Only 1 instance of errsvc exists in the name space > of the application and all modules and libraries it uses. > - Errors (instances of ErrorInfo) are stored in one single list called > _ERRORS > in errsvc.py. > - Engine is going to use errsvc to store exception(s) raised > by checkpoints' execute() method. Engine will use checkpoint name > as the mod_id for the ErrorInfo objects so application can > easily identify which checkpoint failed. > > Problem: > ----------------- > - If the application choose to execute the same checkpoint multiple > times, and all the execution failed, multiple ErrorInfo with the > same mod_id will be added to the list of errors. Application > can not easily figure out which ErrorInfo belongs to which > invocation of that same checkpoint. > > Possible Solutions: > ------------------------------- > 1) engine.execute_checkpoint() will always call > errsvc.clear_error_list() before it executes any checkpoint. > This way, when execution completes, the errsvc > will only contain errors raised during that execution. > The problem with this approach is that > error messages in errsvc that's not stored by the engine prior > to the execution, and not dealt with by the app, will get lost.
I personally don't see any issue with this - if you've got this far and no-one has handled the error, then it's probably not worth remembering... BUT, there would be no harm in logging anything in the error list before you clear it, just for completeness. > > 2) engine.execute_checkpoint() will search the errsvc for > any error associated with the checkpoints it plans to execute, > and remove all those ErrorInfo. The problem with this approach > is that the application will loose information about the > previous exceptions, if they haven't dealt with them already. The error service was never meant to be used this way, and it's not part of it's API to allow this, so doing it could break in the future. > > 3) Move the responsibility to the application to manage the > error list. They should either clear it or remove the ErrorInfo objects > they are not interested in. The engine.execute_checkpoint() > will simplely append to the error list, and return the list of > checkpoints names that failed. It's everyone's responsibility to look for errors - so before Engine.execute() is called, the Application really should have looked for errors that might have occurred so far anyway. Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
