Open AlexRamRam opened 1 year ago
Use of the "fatal" interface for a logging mechanism (to log then system exist) may be a common convention. Golang is one (significant) example:
From a personal experience, I do think something like fatal_system_exit()
would provide better clarity. However, there is a strong argument to close this issue item if fatal
is a well-known convention.
@HalosGhost I will leave the decision of closing this item up to you.
It's not an unheard-of idiom. But, I've never found it well-structured from a separation-of-concerns perspective (seems odd to me that the logger should really be able to control whether execution continues). I'm not particularly certain there's a better plan without rearchitecting a lot of code (this is one of those small implementation detail decisions that has far-reaching effects if you change it because it violates basic separation-of-concerns).
So, I'm comfortable with this being closed, being fixed by a rename, or proposals for something better.
Affected Branch
trunk
Basic Diagnostics
[X] I've pulled the latest changes on the affected branch and the issue is still present.
[X] The issue is reproducible in docker
Description
It's surprising to a reader that the logger object has the power to terminate the program when
fatal()
is called.Consider these alternatives to improve code clarity:
exit()
call fromlogger::fatal()
and client to invokeexit(1)
logger::fatal)
takes additional exit code parameterlogger::fatal()
topanic()
orfatal_system_exit()
Code of Conduct