For the most part, I agree wholeheartedly that these are superfluous and don't need to be there. BUT...

Way too often, the environment is incorrectly configured and because of the lack of error handling in the CMS in general if writing a log statement fails it generally ends up 500'ing the request. There's no reason for that to happen. Other suggestions in the past have been to have the Log class silently catch and ignore Exceptions, which is an even worse architectural design because then you really have no way of debugging why on earth logging is failing short of either a step debugger or stupid API to turn on throwing Exceptions (I hate that option in PHPMailer, FWIW).

So either the error handling in the Log API needs to be adjusted in a way that it can error trap without becoming a black hole or these should remain in place because there is really little realistic reason that a log failure should allow a request to fatally error out.

For reference, the entire chain of PRs attached to #13357

I disagree with this approach. I'd rather expect Joomla to check the correct configuration at one point and/or add a message to the message queue in Log::add() when it fails.

Not everything going to Log::add() should be pushed to the message queue and shown on the screen. So that's not a viable option. They are two different systems and should be treated as such (I still say that jerror category that does exactly this is wrong and should be removed without question).

Like I said, generally I agree that wrapping calls to write to the logs shouldn't be wrapped in try/catch (I don't do this anywhere else). But I feel like Joomla's lack of error handling and the fact that writing a log message can 500 a request is an even bigger issue and removing these try/catch blocks without addressing the underlying architecture issue isn't the best of strategies.

And I did not mean to push the stuff that should go to the log into the message queue, but a message that logging failed because of [reasons].

IMO even that's irrelevant in most cases. Or you end up adding if (Factory::getApplication()->isClient('administrator')) { // do stuff } or if (Factory::getUser()->authorise('core.admin')) { // do stuff } code at a level in the architecture that application or user (group) specific behavior shouldn't exist.

In an environment where you have a build step (i.e. Symfony or Laravel type application where your core services are all booted at the front of the request), you could possibly get away with some kind of config validation and throwing an Exception because at that point the Exception is about being unable to build a core service (so you basically have a Joomla\DI\Exception\DependencyResolutionException on your hands). Since the log API has dynamic registration and can have loggers added at any point in the request cycle, you lose that ability to have an early validation/abort. So now you're left dealing with error detection and handling inside the Joomla\CMS\Log\Logger\FormattedtextLogger class (using that as an example since that's the logger most frequently used). Generally, I'd throw an exception if its text_file_path was a bad value (path doesn't exist, not writable, etc.), but then we're back to having to catch exceptions when calling Log::add() (either wrapping that method or that method internally is handling exceptions) since the actual logger instantiation doesn't happen until the first entry is written to that logger.

Monolog catches all exceptions in its Monolog\Logger::addRecord() method. It has a feature where you can specify an exception handler, and if one isn't set, it just rethrows the exception. Maybe that's a viable approach to re-use within Joomla\CMS\Log\Log::addLogEntry().

I still think that we should find another solution for this, but since there is sooooooo much more to do, I don't think it is usefull to follow up on this now. So I'm closing this PR for the time being.