Filed by @ygoldfeld pre-open-source:
The FATAL severity was recently added to flow.log. suggested we could automatically std::abort() upon logging such a message. He also pointed out that perhaps this should be possibly to enable/disable at compile time (some #define) or even run-time. Personally I am not so sure that needs to be provided on a general-library basis (which Flow is); like to me FATAL means we are really screwed – there is no coming back from it maybe, so abort and hope for the best. Anyway there are various opinions to be had on this.
So I would say in Flow keep it simple: Add a couple of macros to use if desired:
- FLOW_ERROR_ABORT_LOG(…) => FLOW_LOG_FATAL(…); std::abort()
- FLOW_ERROR_ABORT_SYS_ERROR() => FLOW_ERROR_SYS_ERROR_LOG_FATAL(); std::abort()
I figure that decisions as to what one might want to do to conditionally abort() or not, depending on ??? – that can be left to the individual project. After all they can have their own 2 macros named (whatever) that would, e.g.:
- FLOW_ERROR_ABORT(X) or FLOW_LOG_FATAL(X), depending on project-specific ???.
- FLOW_ERROR_ABORT_SYS_ERROR(X) or FLOW_ERROR_SYS_ERROR_LOG_FATAL(X), depending on project-specific ???.
Then you can have each project follow whatever policy makes sense for them.
To be clear – FLOW_LOG_FATAL() continues to be available and won't abort anything. So one can log a number of FATAL messages and then do whatever they feel is right manually.
Filed by @ygoldfeld pre-open-source:
The FATAL severity was recently added to flow.log. suggested we could automatically std::abort() upon logging such a message. He also pointed out that perhaps this should be possibly to enable/disable at compile time (some #define) or even run-time. Personally I am not so sure that needs to be provided on a general-library basis (which Flow is); like to me FATAL means we are really screwed – there is no coming back from it maybe, so abort and hope for the best. Anyway there are various opinions to be had on this.
So I would say in Flow keep it simple: Add a couple of macros to use if desired:
I figure that decisions as to what one might want to do to conditionally abort() or not, depending on ??? – that can be left to the individual project. After all they can have their own 2 macros named (whatever) that would, e.g.:
Then you can have each project follow whatever policy makes sense for them.
To be clear – FLOW_LOG_FATAL() continues to be available and won't abort anything. So one can log a number of FATAL messages and then do whatever they feel is right manually.