Admin app - catch exceptions thrown by JLog::add()

[mbabker]

Partial Pull Request for Issue #13357

Summary of Changes

Logging is not an action that should result in an unhandled error and the user seeing an error page, so catch if a RuntimeException is thrown through the course of calling JLog::add(). This exception may be thrown if JLog::addLogEntry() cannot create the JLogLogger object or an implementation of JLogLogger::addEntry() throws one on a fail state (i.e. the database logger failing to connect to the database or insert the record, or the formatted text logger failing to write to the filesystem).

Testing Instructions

For all cases where logging to a category other than jerror is performed, the exception is just silently ignored. As these are informational log messages only (mainly deprecation notices), there is no need to trigger an error to the UI and notify the user of a failed log statement. For messages categorized as jerror, the catch block will do exactly what JLogLoggerMessagequeue::addEntry() does and call JFactory::getApplication()->enqueueMessage().

This should mean if you make your log directory unwritable, log messages triggered by code in the admin app should not result in the error page being triggered. You might have to programmatically issue a chmod() command before one of these log statements and reset it after to adequately test this until all log statements are wrapped in try/catch.

Documentation Changes Required

N/A

[wilsonge]

Can you fix conflicts here please?

[mbabker]

Tests/reviews here please? Logging shouldn't be a blocking operation, this is one step toward that.

[wilsonge]

Is it not better to call setError here? Especially given this is largely being used for non-html dumps and the view can format handle appropriately

[mbabker]

Well remember, most views have a if $this->get('Errors') style check which basically turns the view into an error page if there are errors found. The current handling of this method doesn't seem to indicate it should cause that to happen.

[wilsonge]

same this file

[mbabker]

This one already has an error set, look above; the $error value comes from $this->getError()

[wilsonge]

Then do we need to do anything other than pass here?

[mbabker]

If this weren't logging to the jerror category I'd just leave a no-op comment. But since the app bootstrap sets up a logger for that category to throw messages in the message queue, I'm doing the same thing in this (and others doing the same) catch case.