Exception vs. JException

[Joe LeBlanc]

I'm noticing in the codebase that there are many places where a
standard PHP Exception is being thrown rather than JException. Also,
LogException and DatabaseException are extended from Exception rather
than JException.

Also, if you throw an Exception from a component (or plugin code that
runs during the component execution), it gets caught and sent through
JError, which ultimately throws a JException.

Since JException is loaded into memory very early in the bootstrap
process, is there any reason we should be using Exception anywhere in
the code?

[Joseph LeBlanc]

Since nobody has replied to this, I'm going to assume that JException is intended to be thrown instead of Exception. My assumption is based on the fact that if you throw a plain exception with an error code like this:

throw new Exception('Whoops, something happened!', 404);

... Joomla will catch that exception, route it through JError, throw a JException object with the 404, which ultimately results in a 404 error code. Running this through JException instead of Exception at least gives developers a place to look for documentation on the behavior.

I'll write some patches to clean it up.

-Joe

> --
> You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
> To post to this group, send an email to joomla-dev...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-frame...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-framework?hl=en-GB.
>

[Mark Dexter]

Hi Joseph. That sounds good to me. I don't think there is any reason
not to use JException consistently (based on my limited knowledge).
Thanks. Mark

[Andrew Eddie]

I've been using Exception myself, but an advantage of using JException
is that we could override getMessage and allow for lazy loading of
error INI files (and that's another topic - language files for
platform strings ...).

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers

[Andrew Eddie]

Actually scratch that, we can handle INI files at the "catch" end. In
that case, I don't think we need JException anymore.

One thing I just came across, though, is how to handle the different
error levels in moving away from JError. For example, the 1.6 way is:

JError::raiseNotice (orange message)
JError::raiseWarning (red message)
JError::raiseError (all stop!)

Now, do they translate to exception codes, or exception classes (or both)?

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers

[Joseph LeBlanc]

Perhaps I'm asking the same question here, but I've also noticed that where JException is used in core, it's usually accompanied by an HTTP error code. Should we then replace "throw new JException" with JError::raiseNotice(), JError::raiseWarning(), and JError::raiseError()? And then use JError::raiseError() for uncaught Exceptions (resulting in a 500 error)?

-Joe

[Andrew Eddie]

I'm pretty sure Louis had some thought on this (I know we've talked
about it but the details escape me). We'd want to head towards just
using exceptions, but we also need the mechanism to raise the error
page as well (whether that's Platform or CMS, I'm not sure - probably
CMS). The Platform, though, should only be throwing exceptions, I
should think.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers

[elin]

JError is currently marked as deprecated in the platform so I guess eventually it's gone, but of course it's still used all over the place. Unfortunately sometimes it's used in too many places in the CMS which is why we see double messages at times in the CMS.

I know that some of us were a bit confused about how to actually get the errors raised and I did see this when doing some work this morning:

   } catch (Exception $e) {

$this->setError($e->getMessage());

return false;

}

Elin

[Joseph LeBlanc]

FWIW, I've worked with other frameworks (Kohana, for one) where errors get generated as pages by the framework, regardless of the HTML in your view. Given that, it wouldn't be inconceivable to have the platform generate an HTML error message with two options:

1) Render a plain error page (similar to the ones in Joomla 1.5)
2) Pass the display onto the application for rendering (have the CMS render the page, while using the HTML generated by the platform)

In any event, I've held off on writing any patches for changing things to Exception, since there are places where JException is thrown with specific error codes.

-Joe

[elin]

Okay, it's official JException is also deprecated.

https://github.com/joomla/joomla-platform/commit/be64bfc72cc0a36dc868bce47cb918088339b915

Elin

[Paladin]

Might be good. It looks like the exception processing bits are in flux
at the moment. Not sure where the ultimate destination is but (my own
tuppence, this) I'm not sure we need a generic custom Joomla
exception. We could make an argument, I think, for custom exception
handlers for a specific area, but Joomla itself is too broad for that.
I'd try to use the standard PHP exception as much as possible, and
only branch out into specialization if it became necessary. Makes it
simpler that way.

I'm more fond of exceptions that log things by default, rather than
display them, because then the exception data is always there to be
examined at a later time. Also, broadcasting error information gives
someone whose intentions are, shall we say, less than pure, a teacup
more information about your system than they had before.

On Jun 22, 5:27 pm, Joseph LeBlanc <cont...@jlleblanc.com> wrote:
> FWIW, I've worked with other frameworks (Kohana, for one) where errors get generated as pages by the framework, regardless of the HTML in your view. Given that, it wouldn't be inconceivable to have the platform generate an HTML error message with two options:
>
> 1) Render a plain error page (similar to the ones in Joomla 1.5)
> 2) Pass the display onto the application for rendering (have the CMS render the page, while using the HTML generated by the platform)
>
> In any event, I've held off on writing any patches for changing things to Exception, since there are places where JException is thrown with specific error codes.
>
> -Joe
>
> On Jun 17, 2011, at 5:53 PM, Andrew Eddie wrote:
>
>
>
>
>
>
>
> > I'm pretty sure Louis had some thought on this (I know we've talked
> > about it but the details escape me).  We'd want to head towards just
> > using exceptions, but we also need the mechanism to raise the error
> > page as well (whether that's Platform or CMS, I'm not sure - probably
> > CMS).  The Platform, though, should only be throwing exceptions, I
> > should think.
>
> > Regards,
> > Andrew Eddie

> >http://learn.theartofjoomla.com- training videos for Joomla 1.6 developers

>
> > On 18 June 2011 07:39, Joseph LeBlanc <cont...@jlleblanc.com> wrote:
> >> Perhaps I'm asking the same question here, but I've also noticed that where JException is used in core, it's usually accompanied by an HTTP error code. Should we then replace "throw new JException" with JError::raiseNotice(), JError::raiseWarning(), and JError::raiseError()? And then use JError::raiseError() for uncaught Exceptions (resulting in a 500 error)?
>
> >> -Joe
>
> >> On Jun 14, 2011, at 8:37 PM, Andrew Eddie wrote:
>
> >>> Actually scratch that, we can handle INI files at the "catch" end.  In
> >>> that case, I don't think we need JException anymore.
>
> >>> One thing I just came across, though, is how to handle the different
> >>> error levels in moving away from JError.  For example, the 1.6 way is:
>
> >>> JError::raiseNotice (orange message)
> >>> JError::raiseWarning (red message)
> >>> JError::raiseError (all stop!)
>
> >>> Now, do they translate to exception codes, or exception classes (or both)?
>
> >>> Regards,
> >>> Andrew Eddie

> >>>http://learn.theartofjoomla.com- training videos for Joomla 1.6 developers

>
> >>> On 15 June 2011 09:45, Andrew Eddie <mambob...@gmail.com> wrote:
> >>>> I've been using Exception myself, but an advantage of using JException
> >>>> is that we could override getMessage and allow for lazy loading of
> >>>> error INI files (and that's another topic - language files for
> >>>> platform strings ...).
>
> >>>> Regards,
> >>>> Andrew Eddie

> >>>>http://learn.theartofjoomla.com- training videos for Joomla 1.6 developers

>
> >>>> On 14 June 2011 23:36, Joseph LeBlanc <cont...@jlleblanc.com> wrote:
> >>>>> Since nobody has replied to this, I'm going to assume that JException is intended to be thrown instead of Exception. My assumption is based on the fact that if you throw a plain exception with an error code like this:
>
> >>>>> throw new Exception('Whoops, something happened!', 404);
>
> >>>>> ... Joomla will catch that exception, route it through JError, throw a JException object with the 404, which ultimately results in a 404 error code. Running this through JException instead of Exception at least gives developers a place to look for documentation on the behavior.
>
> >>>>> I'll write some patches to clean it up.
>
> >>>>> -Joe
>
> >>>>> On Jun 10, 2011, at 11:34 AM, Joe LeBlanc wrote:
>
> >>>>>> I'm noticing in the codebase that there are many places where a
> >>>>>> standard PHP Exception is being thrown rather than JException. Also,
> >>>>>> LogException and DatabaseException are extended from Exception rather
> >>>>>> than JException.
>
> >>>>>> Also, if you throw an Exception from a component (or plugin code that
> >>>>>> runs during the component execution), it gets caught and sent through
> >>>>>> JError, which ultimately throws a JException.
>
> >>>>>> Since JException is loaded into memory very early in the bootstrap
> >>>>>> process, is there any reason we should be using Exception anywhere in
> >>>>>> the code?
>
> >>>>>> --
> >>>>>> You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
> >>>>>> To post to this group, send an email to joomla-dev...@googlegroups.com.
> >>>>>> To unsubscribe from this group, send email to joomla-dev-frame...@googlegroups.com.

> >>>>>> For more options, visit this group athttp://groups.google.com/group/joomla-dev-framework?hl=en-GB.

>
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
> >>>>> To post to this group, send an email to joomla-dev...@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to joomla-dev-frame...@googlegroups.com.

> >>>>> For more options, visit this group athttp://groups.google.com/group/joomla-dev-framework?hl=en-GB.

>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
> >>> To post to this group, send an email to joomla-dev...@googlegroups.com.
> >>> To unsubscribe from this group, send email to joomla-dev-frame...@googlegroups.com.

> >>> For more options, visit this group athttp://groups.google.com/group/joomla-dev-framework?hl=en-GB.

>
> >> --
> >> You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
> >> To post to this group, send an email to joomla-dev...@googlegroups.com.
> >> To unsubscribe from this group, send email to joomla-dev-frame...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/joomla-dev-framework?hl=en-GB.

[Louis Landry]

Sorry I'm late to the discussion.  Arlen and I are mostly in agreement on this one.  I spent quite a lot of time thinking about and discussing what to do about error/exception handling with a few people earlier this year -- and also in that context thinking about JError and JException.  Those two 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.  I think there were some design decisions in it's implementation (and I am largely to blame) 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.  

With the addition of JLog to the platform I 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 off, 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.

You'll find in the platform 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 is a move to provide 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.

Cheers,

Louis

Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org

[elin]

I put a summary of Louis's post here http://docs.joomla.org/Exceptions_and_Logging_in_Joomla_1.7_and_Joomla_Platform_11.1

If someone would like to correct/expand/improve that would be great.

Elin

[Paladin]

Just some further thoughts on the topic of exceptions:

1) I don't think extending Exception for our specialized exception
classes is the right way to go. There are several specialized
exception types in the SPL, we should be building off them if
possible. The SPL has been available by default since the advent of
PHP5, but I'd like to see some details of how many 5.2.x hosts have
disabled it (an advantage of PHP5.3 is that it is no longer possible
to disable SPL). If we find enough cases of SPL being disabled "in the
wild" then a temporary fallback to extending Exception is acceptable,
sometimes bad choices are the only choices we have. Some further
resources on the SPL exception classes:

http://www.php.net/manual/en/spl.exceptions.php
http://www.php.net/~helly/php/ext/spl/classException.html
http://codeutopia.net/blog/2011/05/06/how-to-use-built-in-spl-exception-classes-for-better-error-handling/

2) Avdi Grimm in "Exceptional Ruby" (I know, it's not a book about
PHP, deal with it ;{>}) gives a list of five questions to answer
before deciding if something truly is an exception:

* Is it unexpected? (Note: bad user input is *not* unexpected and
should not trigger an exception. It should be handled in the normal
flow of the code.)
* Am I prepared to end the program? Maybe it's something you can log
and keep going. Maybe you can handle this by ignoring the bad input,
or giving a Not Available message instead of the requested output, and
simply going on with processing.
* Can I punt this up the call chain? Maybe down in the low-level
function isn't the right place to handle the exception, maybe the low-
level method doesn't have enough information to even determine if it's
an exception. Can you refer it back up the chain to code where the
information *is* sufficient to determine if it's an exception and how
it should be handled. Decisions to terminate should be made as high up
the call chain as possible.
* Am I throwing away valuable diagnostics? This is where JLog comes
in. Maybe it's better to just log all the details of what happened,
insert some harmless result or even skip completely that segment of
the processing, and continue.
* Would continuing trigger a less informative exception? Examples
might be getting a null when you wanted a class, which would
eventually cause a bad method error, farther down the line after the
details are lost.

This shouldn't be thought of as a simple process. Proper failure
handling is quite possibly the hardest part of *any* software
development. (Steve McConnell, Code Complete)

> > > >http://learn.theartofjoomla.com-training videos for Joomla 1.6

> > developers
>
> > > > On 18 June 2011 07:39, Joseph LeBlanc <cont...@jlleblanc.com> wrote:
> > > >> Perhaps I'm asking the same question here, but I've also noticed that
> > where JException is used in core, it's usually accompanied by an HTTP error
> > code. Should we then replace "throw new JException" with
> > JError::raiseNotice(), JError::raiseWarning(), and JError::raiseError()? And
> > then use JError::raiseError() for uncaught Exceptions (resulting in a 500
> > error)?
>
> > > >> -Joe
>
> > > >> On Jun 14, 2011, at 8:37 PM, Andrew Eddie wrote:
>
> > > >>> Actually scratch that, we can handle INI files at the "catch" end.
> >  In
> > > >>> that case, I don't think we need JException anymore.
>
> > > >>> One thing I just came across, though, is how to handle the different
> > > >>> error levels in moving away from JError.  For example, the 1.6 way
> > is:
>
> > > >>> JError::raiseNotice (orange message)
> > > >>> JError::raiseWarning (red message)
> > > >>> JError::raiseError (all stop!)
>
> > > >>> Now, do they translate to exception codes, or exception classes (or
> > both)?
>
> > > >>> Regards,
> > > >>> Andrew Eddie

> > > >>>http://learn.theartofjoomla.com-training videos for Joomla 1.6

> > developers
>
> > > >>> On 15 June 2011 09:45, Andrew Eddie <mambob...@gmail.com> wrote:
> > > >>>> I've been using Exception myself, but an advantage of using
> > JException
> > > >>>> is that we could override getMessage and allow for lazy loading of
> > > >>>> error INI files (and that's another topic - language files for
> > > >>>> platform strings ...).
>
> > > >>>> Regards,
> > > >>>> Andrew Eddie

> > > >>>>http://learn.theartofjoomla.com-training videos for Joomla 1.6

> > > > To unsubscribe...
>
> read more »