On Mon, 12 Mar 2012 00:15:14 -0500, Jose Armando Garcia <jsan...@gmail.com>
wrote:
On Wed, Mar 7, 2012 at 7:16 AM, Robert Jacques <sandf...@jhu.edu> wrote:
On Tue, 06 Mar 2012 21:22:21 -0600, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 3/6/12 6:05 PM, Geoffrey Biggs wrote:
That approach means that if I actually do have a fatal error, I can't
mark it as such.
Use log.fatal for those.
Andrei
But fatal "Logs a fatal severity message. Fatal log messages terminate the
application after the message is persisted. Fatal log message cannot be
disable at compile time or at run time." The point is that he want to log a
fatal message and then terminate in a custom manner. I don't see a problem
with convince functions that log and error and then throw, but not having
the option to not throw is an unnecessary limitation.
Okay. Let me say this one last time. If you don't want to assert or
throw don't use fatal and critical. I think we are done beating a dead
horse. Maybe it is not clear from the documentation but the only
reason why fatal and critical exist is because of their assert and
throw semantic. This is also the reason why you can't disable them.
I understand that to a person that has not read the documentation is
may not be clear to them that fatal("message") asserts and
critical("message") throws. Knowing this observation maybe we can
remove these severities and make the behavior more obvious by adding
the tempalte logAndThrow.
Thanks,
-Jose
There is a strong impression that a 'fatal' error and an 'error' will appear
differently in the log file. So long as fatal is anything more than log an
error, flush and throw, there will be people wanting to separate the fatal log
level from fatal log and throw command. I think the logAndThrow will clear up
this confusion.
