Richard,
Now you are a bit all over the place. Yes of course, things can be
handled in a more nice way if we introduce new features.
ARTS is almost 20 years! When we started ARTS the aim was in fact to use
as few "groups" as possible. And I would say that we kept that rule a
long time, but l
Hi Oliver,
Here I will only comment on point 1.
The aspect of running ARTS interactively was not pointed out before and
then not considered in my answers. With that in mind it seems reasonable
to replace most asserts with errors. (Most, as I agree that the index
checking in matpack should be
Hi Oliver,
I mostly agree with this course of action and your analysis. And I agree
it is not be necessary to introduce a new error type. This was a
suggestion to deal with Patrick's speed concerns. I am more worried about
bad program termination and will not run ARTS with such a flag.
I wish
Hi Patrick,
Den mån 25 mars 2019 kl 19:47 skrev Patrick Eriksson <
patrick.eriks...@chalmers.se>:
> Hi Richard,
>
> I can agree on that this is not always critical for efficiency as long
> as the check is a simple comparison. But some checks are much more
> demanding. For example, the altitude
Hi Patrick and Richard,
I think we're mixing up two issues with error handling in ARTS which should be
discussed separately:
1. There are instances where ARTS currently exits non-gracefully which is
painful esp. for python API users.
2. How to better organize where errors are checked and which
Hi Richard,
I can agree on that this is not always critical for efficiency as long
as the check is a simple comparison. But some checks are much more
demanding. For example, the altitudes in z_field should be strictly
increasing. If you have a large 3D atmosphere, it will be very costly to
r
Hi Patrick,
Just some quick points.
Den sön 24 mars 2019 kl 10:29 skrev Patrick Eriksson <
patrick.eriks...@chalmers.se>:
> 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 instea
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 t
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
