And you can't catch the thrown exception because?

I would have to make a

try {
  JLog::add(...);
} catch (Exception $ex) {
  ...
}

around each JLog statement... Someone suggested making a custom logger and inject instead.

But I'm also a bit skeptical if exception is a desired behaviour at all for a logger. Maybe rather return a boolean? Or make it possible to supply an anonymous function which is run at failure.

Yes throwing exceptions is a correct way of raising an error. Monolog's library also throws exceptions for similar conditions.

Also note that an exception may be thrown within the JLog class itself, not just from within the logger classes, so you are not adding a try/catch simply for the default formatted text handler possibly throwing an exception. In fact, depending on what loggers have been registered, it's possible for the exception to come from another source (i.e. if a database logger has been registered and there is a connection/query failure, or a callback logger has been registered and the callback throws one). So your best bet is going to be catching exceptions when attempting to log a message.

Yes throwing exceptions is a correct way of raising an error.

A return code or boolean is also a valid alternative. Just saying.

I don't think we need to be adding more JError style getError()/setError() methods to our APIs, and changing return values is going to introduce B/C breaks or leave the code in a state where everyone just blissfully ignores the fact there has been an error condition. So design wise, I don't feel there is anything to be changed in our API; it is doing what it needs to do and is in line with PHP practices.

I completely disagree, but not sure how to fix it. You should not have to distrust a log statement. Or at least there should be an option to make it less aggressive.

Maybe an ignore errors flag?

https://github.com/Seldaek/monolog/blob/master/src/Monolog/Formatter/NormalizerFormatter.php#L186

Even with an ignore errors flag, what happens? How is it communicated upwards that there was an error that should be checked (because blissfully ignoring errors is worse than not raising one)? Even in that snippet you linked, json_encode() natively returns a boolean false which would tell anything using that formatter that the encoding process failed, so the only thing that changes is the code did not go through the formatter's internal validation and error handling logic.

You are right that you should not have to distrust a log statement, but you should not change the API so that it blissfully ignores error states. Anything making a database call or a filesystem read/write operation (which many of our logging handlers are doing) should be aware that there is the potential for the operation to fail and to be ready to account for that.

You can make a custom log class where you can handle errors in the way you think it is appropiate for your requirements. But expecptions are the right way for JLog.

Yii 2 actually suppresses a lot of function calls: https://github.com/yiisoft/yii2/blob/master/framework/log/FileTarget.php#L104

Unless the file doesn't exist. Hm.