User tests: Successful: Unsuccessful:
Partial Pull Request for Issue #13357
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).
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.
N/A
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_admin com_categories com_config com_content com_contenthistory com_finder com_installer com_joomlaupdate com_languages com_media com_menus com_messages com_modules |
Labels |
Added:
?
|
Tests/reviews here please? Logging shouldn't be a blocking operation, this is one step toward that.
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-02-05 17:04:17 |
Closed_By | ⇒ | wilsonge |
Can you fix conflicts here please?