Improve generic error reporting routines
The following issues for the code under source:src/gromacs/fatalerror/ would be good to consider in order to make the best out of the code:
- Output formatting for fatal errors could be improved by adding line wrapping and by stripping the root of the CMAKE_SOURCE_DIR directory from the reported file names.
- Elaborate the difference between APIError exception and GMX_RELEASE_ASSERT (or is there any?). Which should be used in which situation? Or should GMX_RELEASE_ASSERT throw an APIError on failure? Or should there perhaps be a separate GMX_API_ASSERT for this purpose? If it is necessary to test that an assert works as intended, it is convenient to have the assert throw an exception.
- Consider better error messages for exceptions thrown by the standard library.
- Consider the possibility of printing stack trace for fatal errors and/or failed assertions (at least on some most common development platforms).
- Consider the possibility of installing a signal handler for segmentation faults to produce a reasonable error message and possibly a stack trace.
All of these, except the second one, should be possible to implement without changes to the existing public API. The last one of course needs an additional API, but that shouldn't affect existing functionality.
Error/exception handling improvements.
- Change formatErrorMessage() to printFatalErrorMessage() that directly
prints the error message for an exception into a FILE (typically
stderr) instead of creating a std::string. This makes it possible to
handle out-of-memory errors internally within the function.
The function is much easier to use if we can guarantee that it never
- Add basic handling of std::bad_alloc into the above function.
- Resolve clang warnings in the function.
- Add a macro for conveniently catching all exceptions at C++ - C
boundary and reporting them as fatal errors.
- Initialize ProgramInfo in all C++ binaries.
Related to #838.
More features for TextLineWrapper.
Add more control over formatting the wrapped lines:
- Add possibility to indent the wrapped lines.
- Add possibility to indent the first line after an explicit line break
differently from other lines.
- Add possibility to mark line continuation using an explicit character.
- Add possibility to either remove or keep leading whitespace after an
explicit line break.
All except the last are already useful for the current console output.
Depending on the chosen solution, some or all of these are also needed
Also expose the lower-level interface used internally that makes it
possible to write code that iterates over the wrapped lines and does
something else than just format them into a buffer. May be useful for
some cases in #969, but is necessary to use the wrapper for #838 (line
wrapping in error messages).
Restructure fatal error formatting.
Split printFatalError() in errorformat.h to separate functions that
print the error header, (part of) the actual message, and the footer.
This makes it possible to print the message in calling code
incrementally instead of formatting it into a string buffer.
It is easier to print the message in parts this way, and there is also
less complications in handling possible std::bad_alloc errors from
manipulating a std::string.
Also added line wrapping functionality to the message writing function,
and improved the appearance of the header.
Print more information on exceptions.
- Identify a few more exception types instead of printing "Unknown
exception". Print the dynamic type of the exception for the unknown
exception case as well as some other cases.
- Print errno information if it is included in the exception.
Part of #838.
Treat exceptions better in interactive selections.
If a user input error occurs in an interactive selection parser, the
message is now printed and parsing continues, like it used to work
before exceptions were introduced here. Although most code still does
not use exceptions for user error reporting, this makes the code more
future-proof (and a subsequent commit will add some exceptions that take
advantage of this).
Refactored exception message formatting to support this, removing a TODO
related to duplicated code in the process.