[kepler-users] catching exceptions in batch mode

[Christopher Brooks]

Hi Christine,
The description below is more for Ptolemy, the execution engine that is used
by Kepler.

Classes like ptolemy.moml.MoMLSimpleApplication have a executionError() 
method
that is called when there is an error at runtime.  I'm not sure what 
class Kepler is calling
in batch mode, but if it is not MoMLSimpleApplication, then it is fairly 
similar.

You could modify that method to "do the right thing," though this seems 
awfully model
specific.

Another way is that there are two actors, ThrowModelError and ThrowException
http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII8.0/ptII/doc/codeDoc/ptolemy/actor/lib/ThrowModelError.html
http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII8.0/ptII/doc/codeDoc/ptolemy/actor/lib/ThrowException.html

The docs for ThrowModelError say:

> An actor that throws a model error when it receives a true token on 
> any input channel. The message reported in the model error is given by 
> the /message/ parameter. The inputs are read and checked in the 
> postfire() method only.
>
> A model error is an exception that is passed up the containment 
> hierarchy rather than being immediately thrown. Any container in the 
> containment hierarchy may choose to handle the error. By default, 
> containers will pass and delegate the error to their container, if 
> they have one, and throw an exception if they don't. But some 
> containers might do more with the error.
>

NamedObj.handleModelError() is the code that is called.

http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII8.0/ptII/doc/codeDoc/ptolemy/kernel/util/NamedObj.html#handleModelError%28ptolemy.kernel.util.NamedObj,%20ptolemy.kernel.util.IllegalActionException%29
says:

> Handle a model error. If a model error handler has been registered 
> with setModelErrorHandler(), then handling is delegated to that 
> handler. Otherwise, or if the registered error handler declines to 
> handle the error by returning false, then if there is a container, 
> handling is delegated to the container. If there is no container and 
> no handler that agrees to handle the error, then return false.
>
> A typical use of this facility is where a subclass of NamedObj does 
> the following:
>
>       handleModelError(this, new IllegalActionException(this, message));
>    
> instead of this:
>       throw new IllegalActionException(this, message);
>    
> The former allows a container in the hierarchy to intercept the 
> exception, whereas the latter simply throws the exception. 

handleModelError() is typically called in Modal Models where an error 
transition should be taken.

ptolemy.kernel.util.BasicModelErrorHandler has a handleModelError() 
method that merely
throws the exception.  Classes like ptolemy.actor.gui.PtolemyFrame set 
the model handler to
BasicModelErrorHandler

  _model.setModelErrorHandler(new BasicModelErrorHandler());

So, for actors that throw model errors, you could register a model error 
handler that did
what you want.

To monitor execution status, see ptolemy.actor.ExecutionListener.  You could
use managerStateChanged.  You can also attach a listener to a director 
or actor and
get information that way.   The way the UI implements the "Listen to 
Director" menu choice
is in ptolemy.vergil.actor.ActorGraphFrame.  Search for "Listen to 
Director".
See ptolemy.vergil.actor.ActorController for how "Listen to Actor" is 
implemented.

_Christopher


On 8/24/11 7:13 AM, Smit, Christine E. (GSFC-610.2)[TELOPHASE CORP] wrote:
>
> A lot of the built-in actors throw exceptions in certain situations. 
> Is there some way to gracefully catch these exceptions, particularly 
> when we are running kepler workflows from the command line (i.e. 
> without the GUI)? For example, the XPath Processor throws an exception 
> if it doesn't find the path specified, but this might not always 
> really be an error in an actual workflow. Is there any way we could 
> automatically recover from this error and continue execution?
>
> More generally, is there any way to externally monitor Kepler's 
> execution status?
>
> Thanks.
>
> Christine
>
> --------------------------------
>
> Dr. Christine Smit
>
> christine.e.smit at nasa.gov <mailto:christine.e.smit at nasa.gov>
>
> +1-301-614-5752
>
> NASA Goddard, Building 32, N126-12
>
> Code 610.2
>
>
>
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users

-- 
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841                                (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20110824/53fec8e6/attachment.html>