Exceptions and Errors: what are they used FOR

[garyamort]

Part of the problem of following a discussion on changes to JException and JError is, I believe, a difference in viewpoint.

From the point of view of developing platform code, when an exception is to be thrown that's it, end of the line, abort everything and die.  Provide enough information in the exception for debugging and DIE.

And due to the beauty of Object Oriented Programming and the exception object - throwing the exception is literally all you need.  You don't even need to set a message.  You don't need to subclass it.  Just throw it.

From http://www.php.net/manual/en/class.exception.php 

• Exception::getPrevious — Returns previous Exception
• Exception::getFile — Gets the file in which the exception occurred
• Exception::getLine — Gets the line in which the exception occurred
• Exception::getTrace 

Does a developer want to know what class caused the exception?  getFile and getLine tells you exactly what file is the cause of the problem and therefore what class.

Do you want exhaustive information?  getTrace gives you that.

Is it possible that this exception was triggered by another exception?  Now a problem since if you coded it correctly, then you called 'throw Exception('',$previousException)' and so a call to getPrevious gives that information.

The confusion for me is that when working on a component or module, there may well be error conditions which should NOT terminate the program.  For example, a module to grab the latest stock price every 15 minutes from Google Finance, cache it and display it.  Lots of failure points here:

Unable to grab the latest price: just use the last retrieved price

Unable to cache the data, just display what was retrieved

Unable to grab the latest price AND nothing in the cache: don't display anything

In none of these cases would a site owner want the entire application to die.  It's better to display everything BUT that snippet than to display nothing.

So what SHOULD be done with these?  Well, an Exception should still be thrown, but in this case the Exception be handled and move on.  

From a developer standpoint, to handle this when the framework does not provide it, I should not ever throw a bare Exception.  Instead I should subclass exception:

class GaryException extend Exception {}

Now I can add a custom catcher to just process GaryExceptions.  During development I may want to die at that point and display some good data.  During deployment instead I'll want to notify something internally of the error and keep running.

Now suddenly I have a use for 'codes'.  I might want to classify my exceptions into: 

critical, must be looked at right away

error, module or component had to abort

warning, module or component is not functioning properly

info, temporary issue

In my example, not getting a stock price from google due to a network timeout is informational, network hiccups happen, life goes on.  Not being able to cache the data is a warning because it indicates an underlying issue.  An error might be if using a paid stock ticker api, an invalid userid and password - since that needs to be fixed.

Now, I could use subclasses but that means giving up a lot of PHP's built in functionality or is extremely messy.

If I give up SPL functionality, then I can implement:

CriticalGaryException, ErrorGaryException, WarningGaryException, InfoGaryException

And I am done.

But if I want SPL functionality, I will also need to define a Gary...Exception for all the SPL exceptions(13 of them at the moment) and 4 state levels for each one.

http://www.php.net/manual/en/spl.exceptions.php 

So what an end developer using the Joomla Platform really needs is:

JPlatformException extends Exception and to be nice 13 subclasses such as  JPlatform BadFunctionCallException extends  JPlatform Exception 

Note: I chose JPlatform instead of the traditional JException since there already IS a JException class.

We don't need any codes defined for us since the decision for what to do with different levels of exceptions is something that is dependant on the implementation of the platform, not on the platform itself.

Ideally, there should be follow through on the CMS side to define some codes, JCMSException::CRITICAL, JCMSException::WARNING, JCMSException::ERROR, JCMSException::INFO as well as a plugin configured which can catch all JExceptions[and thus all children of JPlatformException], check the code and either die with the error.php template as it does now or send the exception data to JLog.  This plugin can be configured for what level of exceptions to log and which to abort on.

Then it would be up to each component/application developer.  They can use the built in exceptions, or subclass them for yet more application specific uses.  Personally, I would like to see each developer subclass them to their company/group name.  Ie myCompanyException extends JCMSException.  In that manner, if the error is ever displayed on the website, it provides a clue on whether the problem is in the Platform, the CMS, or in 3rd party code[and if in 3rd party, who the heck to blame!]

As it is right now, with a single error/exception mechanism, it is being used for multiple purposes which leads to confusion.  Core developers don't see a point to all the extra intelligence because when they use it they only want to do one thing: die.  And application developers tend to avoid using exceptions because the impact of how they are used is a showstopper.

If this appears right to others, I'm willing to go ahead and submit a patchfile.  The beauty of this approach is that it's really not that much work since I'm not adding any functionality to the exceptions themselves, just creating 14 subclasses and unit tests for those 14 subclasses.   Document what the purpose of the classes are and how they can be used.  The only functional change would be in JException itself where whenever it currently throws an Exception it now should throw a JPlatformException.

[Amy Stephen]

The discussion to which you are referring is about *existing* Exception reporting. Your points largely propose other ways that the existing Exceptions could be thrown. That's fine, and I believe you have good ideas, but that was not the focus of the discussion at all.

The goal is simply to remove JText messsages and replace I_AM_A_LITERAL_TO_TRANSLATE with 'I am the translated literal.'

That's it.

Concerns were raised about losing the I_AM_A_LITERAL key and the associated translations.

As a result, a very brief discussion about ways to retain a key - primarily for translations - that could be used along with an English description.

That discussion was correctly, in my opinion, put on hold so that we use the short period of time before 12.1 to separate JText. Following that release, people will have more time to participate in the discussion and consider lots of ideas. 

The only "correction" I will make to your comments is that by adding a code, nothing has to change for the calling process. That code can be ignored. The message continues to be returned. Just wanted to clarify that one point.

If you have time to help, it would really be appreciated if you would take on some of the JText removal goal. It's a big job and I am short on time. We could use a few good devs to help.

https://docs.google.com/spreadsheet/ccc?key=0Ai_cbqlzUiyddGlXRDg5XzVacFZNbi1kUV9XOUl4b1E#gid=0
 

[garyamort]

On Tuesday, March 27, 2012 5:02:17 PM UTC-4, Amy Stephen wrote:

The discussion to which you are referring is about *existing* Exception reporting. Your points largely propose other ways that the existing Exceptions could be thrown. That's fine, and I believe you have good ideas, but that was not the focus of the discussion at all.

Hence I started a new message thread to discuss it.  

There are currently 3 methods of indicating a problem.  JError, JException, and JLog

JError was, in general, used to indicate problems during loading a page and JException was hardly used.  JLog would be used to keep track of messages.

The platform code is moving to use JException instead, which makes sense from a platform standpoint - if there is an underlying failure aborting as exceptions do makes perfect sense.

 

However, JError has been depreciated.  Which means at some point that class disappears - so to be forward compatible it is best to have a preferred method of handling things well before JError is removed from the codebase.  My impression had been that JException was that preference, but after reading the other thread my impression now is that there has not been any thought put into the CMS and people using it or their own implementations using the platform.

So I would rather raise the issue now and clarify my mistakes then go and convert all my errors into exceptions only to discover that exceptions are being tuned and stripped of unneeded functionality because their purpose is for platform issues only.

As for modifying the next platform code update, I have a very important code release for this weekend[my first component] - but if tuesday is soon enough, let me know where the issue tracker or list of classes is and I'll do what I can then.

-Gary

[Amy Stephen]

On Sat, Mar 31, 2012 at 2:32 AM, garyamort <gary...@gmail.com> wrote:

On Tuesday, March 27, 2012 5:02:17 PM UTC-4, Amy Stephen wrote:

The discussion to which you are referring is about *existing* Exception reporting. Your points largely propose other ways that the existing Exceptions could be thrown. That's fine, and I believe you have good ideas, but that was not the focus of the discussion at all.

Hence I started a new message thread to discuss it.  

No problem. Your email referred back to the discussion in such a way that it made me think maybe the primary focus was confused.
 

There are currently 3 methods of indicating a problem.  JError, JException, and JLog

JError 

Most JError usage has now been removed from the framework. What remains are the "return JError" statements that are part of this current effort.

JException

Deprecated with 12.1 https://github.com/joomla/joomla-platform/blob/staging/libraries/legacy/exception/exception.php

I have a question in to Andrew in that other thread to confirm this, but I believe we are also replacing JException with a PHP Exception in this latest effort, as well.

JLog

Much of the earlier JError work involved a switch to JLog for messaging. Also, it's heavily used for warning about deprecated method use.
 

JError was, in general, used to indicate problems during loading a page and JException was hardly used.  JLog would be used to keep track of messages.

The platform code is moving to use JException instead, which makes sense from a platform standpoint - if there is an underlying failure aborting as exceptions do makes perfect sense.

JException is deprecated.
 

 

However, JError has been depreciated.  Which means at some point that class disappears - so to be forward compatible it is best to have a preferred method of handling things well before JError is removed from the codebase.  

Already gone.
 

My impression had been that JException was that preference, but after reading the other thread my impression now is that there has not been any thought put into the CMS and people using it or their own implementations using the platform.

The PHP SPL Exceptions are what we are using.
 

So I would rather raise the issue now and clarify my mistakes then go and convert all my errors into exceptions only to discover that exceptions are being tuned and stripped of unneeded functionality because their purpose is for platform issues only.

As for modifying the next platform code update, I have a very important code release for this weekend[my first component] - but if tuesday is soon enough, let me know where the issue tracker or list of classes is and I'll do what I can then.

Your first component? How is that possible? You are so knowledgeable about the framework. It's about time! ;-)

That'd be great - check in when you have time and see where we're at. If that doesn't work, there will be more opportunities going forward. Look forward to working with you.
 

-Gary

Those are just my answers, of course I'm not part of the project or platform team, just working on these patches. Hopefully, someone else will confirm or correct any misunderstandings.

Thanks Gary.