Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I had an instance recently where
lmfit
was raising exceptions to highlight NaNs in either the data or model output when performing optimisation. It turned out that sometimes during optimisation that parameters were set to NaN as they were passed to the residual function, which in turn generates a model made up of all NaNs. This was a little bit of a pain to track down asaegean
correctly masks all NaNs in the data to begin with.Although one could capture the
ValueError
raised bylmfit
, aValueError
is an awfully broad exception and might be a little painful to test against during the exception handling, I thought the better approach would be to have a classAgeanError
class that we can subclass to better handle these strange errors.In this example request I have made an
AegeanNaNModelError
that is raised in the residual function if there are any NaNs, and is capture in the non-priorised fitting routine insourcefinder.py
. This, I think, lets us better handle the cases where there are errors we do not care about, and still correctly raise new ones we don't currently know about.