Actions

J2.5

Difference between revisions of "Exceptions and Logging in Joomla Platform 11.1 and Joomla 2.5"

From Joomla! Documentation

(Created page with "{{JVer|11.1}} {{JVer|1.7}} Summarized from https://groups.google.com/d/topic/joomla-dev-framework/kwqjy1Goj0w/discussion Mailing List Thread The Joomla Platform 11.1 change...")
 
(Add in Database Exception Link)
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{JVer|11.1}} {{JVer|1.7}}
+
{{version|1.7|platform=11.1}}
 
+
 
Summarized from [[https://groups.google.com/d/topic/joomla-dev-framework/kwqjy1Goj0w/discussion Mailing List Thread]]
 
Summarized from [[https://groups.google.com/d/topic/joomla-dev-framework/kwqjy1Goj0w/discussion Mailing List Thread]]
  
The Joomla Platform 11.1 changed the way to handle exceptions and logging and deprecated JError and JException.
+
The Joomla Platform 11.1 changed the way to handle exceptions and logging and deprecated [[JError]] and [[JException]].
  
 
==Background==
 
==Background==
Line 13: Line 12:
 
In the 11.1 platform there are blocks like:
 
In the 11.1 platform there are blocks like:
  
// Legacy error handling switch based on the JError::$legacy switch.
+
// Legacy error handling switch based on the JError::$legacy switch.
// @deprecated  11.3
+
// @deprecated  11.3
if (JError::$legacy) {
+
if (JError::$legacy) {
  JError::setErrorHandling(E_ERROR, 'die');
+
  JError::setErrorHandling(E_ERROR, 'die');
  return JError::raiseError(500, JText::sprintf('JLIB_DATABASE_ERROR_LOAD_DATABASE_DRIVER', $options['driver']));
+
  return JError::raiseError(500, JText::sprintf('JLIB_DATABASE_ERROR_LOAD_DATABASE_DRIVER', $options['driver']));
}
+
}
else {
+
else {
  throw new DatabaseException(JText::sprintf('JLIB_DATABASE_ERROR_LOAD_DATABASE_DRIVER', $options['driver']));
+
  throw new DatabaseException(JText::sprintf('JLIB_DATABASE_ERROR_LOAD_DATABASE_DRIVER', $options['driver']));
}
+
}
 +
 
 +
This provides a level of backward compatibility as we transition off of the deprecated JError/JException classes.  Essentially if the JError::$legacy flag is true we'll use the old JError behavior, but otherwise we are going to just throw a [[DatabaseException]] which in this case is purely class DatabaseException extends Exception {} so that we have a little more specificity in exception type, not an adjustment in behavior.
  
This provides a level of backward compatibility as we transition off of the deprecated JError/JException classes.  Essentially if the JError::$legacy flag is true we'll use the old JError behavior, but otherwise we are going to just throw a DatabaseException which in this case is purely class DatabaseException extends Exception {} so that we have a little more specificity in exception type, not an adjustment in behavior.
+
[[Category:Development]]

Revision as of 14:03, 4 February 2013

Summarized from [Mailing List Thread]

The Joomla Platform 11.1 changed the way to handle exceptions and logging and deprecated JError and JException.

Background

The JError and JException classes were added to the Joomla framework back when PHP 4.1 was our minimum requirement. They were included so that we might have some semblance of an exception object / error flow in a language that wasn't quite there yet. For better or worse that's the history. There were some design decisions in its implementation that really mixed concepts in a way that isn't healthy. If you think about what JError does, it mixes the concept of error handling with logging.

The addition of JLog to the platform attempted to really make our logging system much more robust, configurable and simple to use. It didn't make sense to throw exceptions for all of the things we would previously have returned JExceptions. First, we sometimes would JError::raise() a warning or notice and then continue on with execution. That isn't really possible since throwing an exception is going to halt execution until it is caught, and that doesn't even get into the fact that it isn't what an exception really is. In that case what really needs to happen is that a warning or notice needs to be logged and continue on with execution. If an actual error condition occurs that is severe enough for an exception, then it should be treated as such. This is simply more in line with modern programming practices.

In the 11.1 platform there are blocks like:

// Legacy error handling switch based on the JError::$legacy switch.
// @deprecated  11.3
if (JError::$legacy) {
  JError::setErrorHandling(E_ERROR, 'die');
  return JError::raiseError(500, JText::sprintf('JLIB_DATABASE_ERROR_LOAD_DATABASE_DRIVER', $options['driver']));
}
else {
  throw new DatabaseException(JText::sprintf('JLIB_DATABASE_ERROR_LOAD_DATABASE_DRIVER', $options['driver']));
}

This provides a level of backward compatibility as we transition off of the deprecated JError/JException classes. Essentially if the JError::$legacy flag is true we'll use the old JError behavior, but otherwise we are going to just throw a DatabaseException which in this case is purely class DatabaseException extends Exception {} so that we have a little more specificity in exception type, not an adjustment in behavior.