Hello, I did a commit with the changes made to functions in array.c. I would like to know your feedback on this so that I can share the rest of the work.
commit link: https://github.com/fathmamehnoor/gnuastro-dev/tree/add-error-reporting

I've been working on the new error.h module for the library. After many discussions, we decided to go with the gal_error_t structure to hold a list of all the errors encountered as suggested by Mohammad. However, a few additions have been made:

typedef struct gal_error_t
{
  uint8_t code;              /* Code of the problem wrt to each library.*/
  uint8_t lib_code;          /* Library which created the error.        */
  uint8_t is_warning;        /* Defines if the error is only a warning. */
  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;

Here, the 8 bit library code(`lib_code`) indicates which library
generated the error. All libraries have their own unique
code defined in alphabetical order inside an enum.

8 bit flag indicating if the error is a breaking error or just a warning(`is_warning`).

The 8 bit error typecode(`code`) indicates the type of error within that library. Each library has its own error types defined as 32-bit macros. These macros are constructed to hold the value of all three above-mentioned attributes.

I've also added some basic functions for error handling and parsing of the gal_error_t structure. The cosmology module has been changed to now use this new error module.

Here is the commit with the work done till now:
https://github.com/Jash-Shah/gnuastro-jash/commit/f8fd0a8ccdc863ac0b430da2ce3c28d0be86e13e

After some discussions with Pedram and Jash on #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...