VB_handle_diverging_ME about bayem HOT 4 CLOSED

Excellent idea! One the one hand, we must avoid the "catch everything" pitfall. On the other hand, we do not know what exactly to catch. So my preferred solution is to have a tuple of allowed exceptions in VBOptions, essentially:

def f_with_value_error(x):
   return int("I am not a number")

result = bayem.vba(f_with_value_error, ...) # fails
result = bayem.vba(f_with_value_error, ..., allowed_exceptions=(ValueError,)) # result.success = False, but you get some values
result = bayem.vba(f_with_value_error, ..., allowed_exceptions=(IndexError,)) # fails (which is important to find bugs!)

internally, this then simply

...
try:
   k, J = self.p(self.m)
except self.options.allowed_exceptions as e:
   self.result.success = False
   self.result.exception = e  # or logger.error(e)
   # ... whatever cleanup
   return self.result

from bayem.

I think, at this point we are not going to uncover the reason behind any exception. That would be the duty of the user, I suppose. I would say, the VB can stop iterating due to ANY exception emerging in the evaluation of the model error and its jacobian, however, the VB must return proper WARNING messages to the user; e.g. hey :) , something has gone wrong in the model evaluation and therefore I stopped iterations. Makes sense?

from bayem.

For me, it is very important to know how the code fails (and it also should for you). So if you expect VB to fail because of convergence issues in FEniCS, but it actually fails because of a typo (likely to result in an AttributeError), you should get a real, severe error. Not just a printed message that is likely lost in some logs.

But if you still want this behavior, you could always pass allowed_exceptions=RuntimeError and catch everything...

from bayem.

Solved via #88

from bayem.