Ah, I didn't look at the constructor code of that exception. For a simple reason: I didn't expect it to do something like logging the message somewhere. Is this really necessary for constructing the object? I doubt it. In fact it's so unessential that
new fatal_exception("FATAL: Could not init class $class"); only for logging a certain message looks weird to me. If this class wasn't yours would you have expected something like this? Or let me ask it in another way: Would you have thought of or searched in this way if you had been looking for a logging mechanism?
It also generates an (in my view) unnecessary strong (but weak featured) coupling with this e_log class: specified classname, only default logger available, two functions in this class required (for only one purpose) - and again: all this still only for constructing the object.
And last but not least, not everything,anything has to be logged. It's like the personal firewall constantly crying wolf. It's annoying and distracting. Why would I want an unconditional message logging if all that happend was the construction of a simple object? It also somehow contradicts the usefullness of exceptions.
(sorry, have to go right now, only short form for now)
a()->b()->c()->d(). Now an exception occurs in d(). But b() and c() do not care, all they have to do is ...not to do anything, only a() cares about that the execution somehow was aborted. In the old days without exceptions d() hat to return an error code, c() had to check it and also to return it. Same with b ...extra code ...extra code ...extra code without real meaning. Now you throw an exception in d() and since c() and b() do nothing it (more or less) directly ends in the catch block of a(), no extra code in b() and c() for "i really do not care". That's the beauty of exceptions. And that's why I wouldn't want exception handling (like logging) in the constructor of my exceptions
