J2.5:Exceptions and Logging in Joomla Platform 11.1 and Joomla 2.5

The "J2.5" namespace is a namespace scheduled to be archived. This page contains information for a Joomla! version which is no longer supported. It exists only as a historical reference, it will not be improved and its content may be incomplete and/or contain broken links.

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.