Error handling strategy

[zhardy-lanl]

Define an error handling strategy to use throughout the code base. Particularly, determine if the use of macros should remain.

Edit May 29, 2024:

• Implement base Exception class and replace the macros with throws
• Replace calls to terminate with throws

Ref #64

[andrsd]

Here are my thoughts on this problem:

1. Personally, I think that macros should be used as least as possible in any modern C++ code. One can see that the newer C++ standards are moving away from them. One of the biggest problems with macros is that they do not belong to a namespace, thus they need to have some prefix to avoid name collisions. This may seem like a minor issue, but it's a bigger problem that it looks like (in my experience). Also, no type safety - very big problem.

2. My idea of error handling would look like this. There would be an Exception class that would inherit from std::exception and would be part of opensn namespace. If the code needed to throw an exception, developers would simply do: throw Exception("text"). The reason for this class is so that application code can distinguish between exception thrown by OpenSn and by some other parts of the code like std::exception caused by what ever STL errors occur, or by a third party package, etc.

3. If needed there can be more Exception classes that would inherit from the base Exception. For example, something like InternalErrorException for really screwed up problems that almost never happen, but theoretically they could. The number of these exceptions should be quite small. Typical problem is "what kind of exception do I use for what kind of a problem". For example, there could be an exception when a LUA API is called with wrong arguments. That has quite direct mapping. But, there should not be an explosion of different kinds for every little problem.

4. The use of macros in the current code. The one and probably the only reason is that the current design wanted to tell the application where the problem occurred by printing the file name and the line. This can be done in C++17 only via macros (C++20 has something for it, IIRC). This could be helpful, however the call stack and the origin of the exception can be easily captured by running in debugger. Developers should be able to do this, it is not a rocket science. On the other hand, if a user triggers an exception, they could submit this information. But, if we do not have the minimal example that triggers that problem, we cannot do much about it and we would be asking the user to submit such example, or submit an issue with steps how to reproduce and then we do not need that information. In any rate, problems should be reported via issue tracker with steps to reproduce - it a standard practice. If we cannot reproduce the problem, there is no way we can fix it anyway... This to me disqualifies the use of macros for error handling.