Joomla! Discussion Forums

Hello all,

I thought I would quickly go over one of the changes in the upcoming 1.5 release.  Though it was not part of the original roadmap for 1.5, the team determined that it would be beneficial to have a common error manager in Joomla.  This would provide a common interface for both the core and 3rd party developers to handle errors.  After some research was done, the decision was made to wrap the existing patError class that is packaged with patTemplate.  This system provides a whole host of functionality and remains quite lightweight considering its power.  The necessary functionality has been wrapped by a new static class called: JError.

For an overview of how patError works please see: http://www.php-tools.net/site.php?&file=/patError/overview.xml

For online documentation of patError please see: http://www.php-tools.net/site.php?&file=patError/doc/intro.xml

Obviously we will be creating our own documentation and a how-to guide for third party developers as well.  The JError class can be seen in the file: JROOT/libraries/joomla/classes/error.php

A couple of the advantages of using this class will be that all error conditions will have a universal look/feel for the user, and if used properly the user would have exactly the information needed for a developer to fix a bug.

Also, an error system template has been created for displaying errors.  This goes a long way to keeping Joomla looking good, even in the worst of times


Obviously more information to come...

Louis

Sounds great!

Sounds greet indead. For developers it's very welcome and I hope it speeds up development. Error handling eats up most of my time 

Sounds great. Some examples on how to put it to good use in a joomla application would be nice... Or some pointers to core Joomla code that uses it perhaps?

We will try to provide more documentation in the coming weeks. The error handlers are used in the different classes in the framework. A good start is the JFTP class.

The JFTP class ideed uses the JError class extensively. I still have to probe a bit further on these error codes.... :)

To sum up: How does one put the error codes to good use when developing third party components?

For instance, from the mkdir function in the JFTP class there is this line of code:


Why is the error code 35 used in here? What good does it do? What does it refer to? Will this result in a 500 error since it is not a 403 or 404?

Louis wrote this paragraph in the dev blog:


Does he mean "...if access isn't forbidden and the page is available..." (403 or 404) then the error is an internal server error (500)?

The links the documentation and overview are not correct after the recent change on their site:

Try this instead:
http://trac.php-tools.net/patError/wiki
http://trac.php-tools.net/patError/wiki/Docs

I've fixed the only link I know about (http://dev.joomla.org/component/option,com_jd-wiki/Itemid,31/id,guidelines:jerror/).

Please let me know if you are aware of any other bad links.

Thanks Phil.

Regards,
Chris.

Hi,

Just thought I'd add a quick note to say that the JError class is no longer dependent on patError.

If someone has the time to re-read and revise (or even extend!) the Joomla! Error Handling guidelines page: http://dev.joomla.org/component/option,com_jd-wiki/Itemid,31/id,guidelines:jerror/ I would be very grateful.

Please submit your amendments here: http://forum.joomla.org/index.php/board,287.0.html.

Regards,
Chris.

I tried executing a mysql query after calling JError::raiseError(); to log errors, but it looks like it doesn't work. Does raising an error block mysql queries? The specific method I was calling is insertObject.

Regards,
Todd

I think Exceptions would be a great addition. The next version should go fully PHP5.

Nothing wrong with using regular PHP Exceptions. JError::isError($obj) is fully capable of determining if $obj is a JException, JError og regular PHP Exception object.

Note:
JException also uses the same function names as the regular PHP Exception class, so it doesn't even take any time getting used to

I have another question though, related to errors:

How is the JObject error functions intended to work into this? Most classes inherit from JObject and can thus use the error-related functions from JObject, but what is the thought behind for instance setError, getError and getErrors? Are we supposed to use this as a storing mechanism for storing multiple errors?

Yes, the idea is that you can store multiple errors in the object. These errors can be errors, notices, warnings or messages and can be retrieved to be acted upon.

This sounds great... I hope er can use it soon .

We look forward to the development of you.