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 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
