gnuastro-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[task #16263] Errors in the library: remove all exit() calls


From: Mohammad Akhlaghi
Subject: [task #16263] Errors in the library: remove all exit() calls
Date: Mon, 19 Sep 2022 12:32:57 -0400 (EDT)

Update of task #16263 (project gnuastro):

                 Summary: Remove all exit() calls within the library => Errors
in the library: remove all exit() calls

    _______________________________________________________

Follow-up Comment #1:

After some discussions with Pedram and Jash on #gnuastro-dev:openastronomy.org
<https://openastronomy.element.io/#/room/#gnuastro-dev:openastronomy.org> we
have made some general progress in the concept. 

In summary, currently, the error messages in Gnuastro's library are very
elaborate and customized for each function, and each input, including even
solutions based on where they happen. This type of customized error messages
are not possible with merely passing an integer. We can therefore have a
structure like the following to have the best of both worlds: 1. generic
integers to help the high-level caller decide what to do, and 2. a full
string, with a detailed description of that particular situation, 3. a pointer
to a 'next' element, to let the caller accumulate the messages if they need
to.


typedef struct gal_error_t
{
  int code;                  /* Generic code of the problem.  */
  char *back_msg;            /* Detailed message of backend (library) */
  char *front_msg;           /* Detailed message of front end (caller). */
  struct gal_error_t *next;  /* Next error message.           */
} gal_error_t;


To be very generic (also looking from a high-level perspective), the caller
may also like to add a message (for example saying that "we tried function XXX
with parameter YYY, but it failed with the following error"). 

Each library can have its own set of codes to help the caller account for
different types of errors without having to parse the message. But the
messages are very useful for the user of the high-level program (like the
Python modules).

We can have specialized functions to deal with this structure (like adding an
item, printing them in a uniform format and etc. 

We can implement this in the functions that currently call 'error()' 

1. They can be given an extra 'gal_error_t **' pointer as an argument.
2. We can add 'gal_error_t' as an element of 'gal_data_t', so the functions
that return a 'gal_data_t' can simply set that pointer within the returned
dataset. For the functions that don't return 'gal_data_t' we can revert to
case 1. 

Please share your thoughts on these proposals here...


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/task/?16263>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]