Hi Richard,
A great initiative. How errors are thrown can for sure be improved. We
are both lacking such checks (still to many cases where an assert shows
up instead on a proper error message), and they errors are probably
implemented inconsistently.
When it comes to use try/catch, I leave the discussion to others.
But I must bring up another aspect here, on what level to apply asserts
and errors. My view is that we have decided that such basic functions as
planck should only contain asserts. For efficiency reasons.
For a pure forward model run, a negative frequency or temperature would
come from f_grid and t_field, respectively. We decided to introduce
special check methods, such as atmfields_checkedCalc, to e.g. catch
negative temperatures in input.
When doing OEM, negative temperatures can pop up after each iteration
and this should be checked. But not by planck, this should happen on a
higher level.
A simple solution here is to include a call of atmfields_checkedCalc
etc. in inversion_iterate_agenda. The drawback is that some data will be
checked over and over again despite not being changed.
So it could be discussed if checks should be added to the OEM part. That
data changed in an iteration, should be checked for unphysical values.
That is, I think there are more things to discuss than you bring up in
your email. So don't start anything big before we have reached a common
view here.
Bye,
Patrick
On 2019-03-22 16:34, Richard Larsson wrote:
Hi all,
I have kept running into problem with errors in ARTS produced by bad
input for OEM. Asserts are and not exceptions terminate the program in
several cases.
I just made a small update to turn several errors affecting Zeeman code
that before could yield assert-errors into try-catch to throw
runtime_error(). This means I can catch the errors properly in a python
try-except block. The speed of the execution of the central parts of
the code is unaffected in tests. I need input from the ARTS developers
if the way I did this is stylistically acceptable or not.
When updating these error handlers, I decided to use function-try-blocks
instead of in-lined try-blocks. I shared some code with Oliver, because
of the errors above, and he suggested against using function-try-blocks
and follow the traditional system of keeping all the error handling
inside the main block. However, he later in the conversation also
agreed with me that it makes it much easier to pass errors upwards in
ARTS from the lower functions if we use function-try-blocks since all
the function calls of a function are then per automatic inside a
try-catch block. So we decided to run the stylistic question by everyone.
Please give me a comment on if this is OK stylistically or not in ARTS.
I find the function-try-block cleaner since all the error-printing code
is kept away, but if others disagree it just complicate matters.
The easiest demonstration of this change is in the updated
src/physics.funcs.cc <http://physics.funcs.cc/> file. Please have a
look at the two "planck()"-functions. Both versions only throws (const
char * e) errors themselves and turns them into std::runtime_error
before re-throwing. However, this means that the VectorView version of
the function can see an error that is (const std::exception& e) because
the catch-block of the Numeric planck() function turns it into one. And
since all errors in ARTS has to be runtime-errors for the user, it can
also know that any upwards forwarding will deal with runtime-errors.
With hope,
//Richard
The src/physics_funcs.cc planck() error handling:
If the planck() Vector-function is sent a negative temperature, the
error it produces will look as such:
Errors in calls by *planck* internal function:
Errors raised by *planck* internal function:
Non-positive temperature
If the planck() Vector function is passed a frequency vector as [-1 -0.5
0 0.5, 1], the error it produces will look as such:
Errors in calls by *planck* internal function:
Errors raised by *planck* internal function:
Error: Non-positive frequency
You have 3 frequency grid points that reports a non-positive frequency!
Ps. To not have to search.
Function-try-block form: void fun() try {} catch(...) {}
Inline form: void fun() {try{} catch(...) {}}
Same length of code. Function-try-blocks do not have the variables
before the throw-statement available for output, they have to be thrown
to be seen. However, you can perform most if not all computations you
wish inside the catch-block. Like the error counter I made for f-grid
in the *planck* function's catch above.
_______________________________________________
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
_______________________________________________
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
