Review of Jose Armando Garcia Sancio's std.log

[Jose Armando Garcia]

On Mon, Mar 5, 2012 at 3:26 PM, David Nadlinger <code at klickverbot.at> wrote:
> Just a quick reply, more tomorrow:
>
>
> On 6 Mar 2012, at 0:03, Jose Armando Garcia wrote:
>>
>> What is your objection here? I don't remember reading your thoughts on
>> critical.
>
>
> Darn, my longer review post apparently didn't make it through the new web
> interface; hope I can dig it up again… Anyway, my main reservations about
> critical are that a CriticalException in my opinion has absolutely no
> semantic value (compared to e.g. a FileNotFoundException or at least
> FileException thrown from file I/O code).
>
> While I guess it works for programs where you know there is no way you can
> handle the exception and just want to do some rudimentary clean up before
> aborting with a message box/…, I wouldn't want to let it bubble up through
> any of my APIs if I'm writing a library, because there is no way a user can
> know how to handle it without the semantical meaning being defined (maybe in
> the docs, along the lines of »the program should assume nothing and shut
> itself down as quickly as possible« or whatever you design intention was).
>
> Makes sense?
>

Yep it makes sense. I was thinking about it this morning. My current
thinking is to add overloaded methods that look as follow:

critical(new Exception(...), "format string", params...)

This method records the message, exception and throws the exception specified.

error(new Exception(...), "format string", params...)

This method records the message and exception.

Everything else well stay the same. In other words if you don't pass
an exception to critical then it just throws the default exception:
CriticalException.

Or our other option is just to throw our hands in the air and decide
not to solve this problem. In other words remove Severity.fatal and
Severity.critical. Thoughts?

-Jose