Improve exception handling in ReactorNet

[GoogleCodeExporter]

Hi,

the exception handler in ReactorNet::eval() calls error(), which terminates the 
program. The comments say that the call to error() is due to CVODE being a C 
library and therefore unable to handle exceptions, and they suggest to 
reimplement error() appropriately as a work-around for applications where 
termination is not desired.

IMHO this is counterintuitive, inconvenient and perhaps unnecessary.

Here is my suggestion:

 * alter cvodes_rhs such that it catches any error occurring during the eval
   call and returns -1 in case of an error. The -1 return value tells CVODES
   that an unrecoverable error occurred.
 * remove the error handler in ReactorNet::eval and the evalJacobian function
   (There may be other places, the Reactornet is the only class that concerns me 
   here..)

This way, while the original exception is still lost, at least a CVodesErr will 
bubble back to a users' C++ code and enable them to use

 try {
   rn->advance(t);
 } catch(...) { .. }

to prevent crashes.

Since the error messages are also stored in the application object, meaningful 
error information can be retrieved in the catch-Block.

I'll attach a patch against Cantera 2.0, which I wrote as a proof-of-concept. 
As stated above, I only changed the calls in the 0-d ReactorNet, there may be 
other places where this change could be appropriate.

Original issue reported on code.google.com by phillip....@googlemail.com on 9 Oct 2012 at 12:04

Attachments:

• intError.diff

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by phillip....@googlemail.com on 9 Oct 2012 at 12:07

Attachments:

• intError.diff

[GoogleCodeExporter]

This behavior has already been changed in trunk to behave more-or-less as you 
suggest. See r1780 and r1781.

I consider the error stack to be deprecated, so instead the .what() method of 
the caught exception is printed to stderr before returning the appropriate 
error code to CVODE. The evalJacobian function hasn't been updated because it's 
never actually used (and should probably just be removed).

Original comment by yarmond on 9 Oct 2012 at 4:22

• Changed state: Fixed