What to use instead of JError?

[TDZWeb]

I see that the JError has been deprecated. I am a bit of an amateur and have a few questions. Going through exising code, there are a lot of custom error codes for Joomla. Now that JError is deprecated, what are we supposed to replace it with? PHP trigger_error? I can see a lot of people now making their own custom exception classes for their extensions. Isn't this a huge potential source of bugs? For instance if several running extensions/plugins use their own custom exception classes and error handlers.

[Troy]

from what I can see in the docs thats correct... JError is deprecated use PHP exceptions instead

Bear

On 7/28/2012 6:33 PM, TDZWeb wrote:

I see that the JError has been deprecated. I am a bit of an amateur and have a few questions. Going through exising code, there are a lot of custom error codes for Joomla. Now that JError is deprecated, what are we supposed to replace it with? PHP trigger_error? I can see a lot of people now making their own custom exception classes for their extensions. Isn't this a huge potential source of bugs? For instance if several running extensions/plugins use their own custom exception classes and error handlers. --
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/YU2IR4avpIMJ.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[b2z]

Hi!

Can someone provide info about that? And interesting to know - why this was done :)

Best regards,

Dmitry.

[b2z]

Nevermind, I found it :)

https://groups.google.com/forum/#!topic/joomla-dev-framework/kwqjy1Goj0w/discussion

http://docs.joomla.org/Exceptions_and_Logging_in_Joomla_1.7_and_Joomla_Platform_11.1

понедельник, 30 июля 2012 г., 14:15:12 UTC+3 пользователь b2z написал:

[TDZWeb]

Thank you, that was the information I was looking for.

[hoochicken]

Hello,
I've started using exceptions and I like it.
The mechanism itself works, yet I don't know, how to display the exception messages.
The following code failed (I put it in the administrator/componentName/controller/componentName.php::save() just for testing):

try {throw new JException(JText::_('COM_MYCOMPONENT_FORM_INVALID'), 101);}
catch (JException $e) { ?$e->setError($e->getMessage());?OR?$this->setError($e->getMessage());? }

Of course messages might be displayed via JError::raiseNotice(), but as JError is depricated methinks this is not wise.
So question: how can I display the exception messages,
thank U for any reply:-)
Greetings
Mareike

[Christoforos Korifidis]

You can use JFactory::getApplication()->enqueueMessage(JText::_('SOME_ERROR_OCCURRED'), 'error');
you can find more info here
http://docs.joomla.org/Display_error_messages_and_notices

[Johan Högdahl]

php has good stuff built in.

To program for joomla you allready have to know some php, why have to learn new functions overloading whats there.

Why dont add error_log(..) for everything the user is not expected to see.

If it is something the user should handle .. a message should popup

Mostly the user cant do much about the errors,  so to throw a message dont help much.

error_log logs in apacehe's (webservers) error log, but can also send mails.

It would not be a bad thing if you could trac down errors by loggs, and if developers got errors in the mail... the wery soon would have done a fix for it :-')

Johan

[Dmitry Rekun]

Well I prefer to log not to Apache's logs, but to Joomla's logs folder. First I set up logger and Exceptions in the entry point:

// Set up logger
JLog::addLogger(
    array('text_file' => 'com_mycomp.php'),
    JLog::ALL,
    array('com_mycomp')
);

// Use PHP Exceptions
JError::$legacy = false;

Then depending on the situation I throw an Exception (Joomla will handle it) or show some generic error to the user and log an exception message.
public function display($tpl = null)
{
    try
    {
        $this->item = $this->get('Item');
        $this->prepareDocument();

        parent::display($tpl);
    }
    catch (Exception $e)
    {
        if ($e->getCode() == 404)
        {
            // Not found situation
            throw new Exception($e->getMessage(), 404);
        }

        // Generic error situation
        JFactory::getApplication()->enqueueMessage(JText::_('COM_MYCOMP_ERROR_OCCURRED'), 'error');
        JLog::add($e->getMessage(), JLog::ERROR, 'com_mycomp');

[Johan Högdahl]

There are things which are good and bad with using JLog when developing..

JLog is in the system and there are tools to handle it.

There does not seem to be any tools to show it online (auto updating) , could have been nice :-')

But JLog will not log PHP errors ( as far as i know. )

And i have no idea if it has any function for rollover or if it will grow very large or fill the system.

JLogLoggerSyslog is there .. but very hard to find documentation on how to set it as default for Joomla.

Checking the code .. i would say someone had forgotten to override the add function and therefore it 

it will probably not work together with JLog as well as it could have done.   

If you uses apaches log  (error_log(..))you know its system handled and will not fill the system.

All errors will be logged in one place. Therefore its easy to see what happened and in which order.

You also get loggings on not found url's which is good when you have given the wrong part or forgot to bypack som files.

Whats not so good is you can't  set an error leve.. everything is logged as errors.so you hawe to put something there which tells if its a real error or some trace.

All this is naturly a matter of taste. 

Both ways will work and it depends on what you are logging which is  best to use.

Johan

[Johan Janssens]

Hi Hoochicken

There are 2 ways to deal with exception messages in Joomla (and in general).

1. A recoverable exception

If you are recovering from an exception using a try {} catch() {} block but you still want to inform the user that something went wrong you can use the error messages API, see : http://docs.joomla.org/Display_error_messages_and_notices

For example, if data validation failed after a form submit and a validator throws an exception you can catch it and inform the user that the validation failed and the reason why. 

2. A unrecoverable exception

Your code can also throw exceptions itself, you do not necessarily need to catch those exceptions. Uncaught exceptions are turned into errors by PHP itself, or they can be caught with a user defined exception handler, see http://www.php.net/manual/en/function.set-exception-handler.php Please take note that only one user defined exception handler can exists. 

Joomla 2.5+ also catches any exceptions thrown by a component during the component dispatching phase and transforms them into error using JError. See : https://github.com/joomla/joomla-cms/blob/2.5.x/administrator/includes/application.php#L129 

Note : I'm unsure if this is the same in Joomla 3, the catch block is not there anymore in the codebase. I suspect it was either moved or removed. 

I hope that helps,

Johan

[Johan Janssens]

Hi Dmitry,

What you are doing here is not ideal in case of a 404. You are recovering from the 404 by showing the user a error message, and logging the error at the same time.

A 404 not found error should produce a 404 status response to the client (browser). By recovering from the error and letting Joomla continue rendering the page you are actually returning a 200 OK status code. This is not correct accoording to the HTTP spec. If a resource cannot be found the server should return a 404 (http://en.wikipedia.org/wiki/HTTP_404)

A better approach would be to not catch the exception, or to throw a special NotFound() exception instead and make sure you are setting the status header to 404. eg header("HTTP/1.0 404 Not Found", true, 404); 

If you wish to log the 404 you could still do so by building a system plugin that would check the status header and log any responses that are not 2xx. By using a plugin you are also decoupling your logging system from the actual exception handling as both are different responsibilities. 

Happy coding!

Johan

[Johan Janssens]

Johan, 

For a very good PHP logging package have a look at Monolog : https://github.com/Seldaek/monolog It comes with many different handlers that you can setup for your application and has good documentation.

Little note, if you use error_log errors will be logged to the to the file defined by error_log configuration setting in PHP, see  http://www.php.net/manual/en/errorfunc.configuration.php#ini.error-log  On a shared or virtual host this will be the apache log, or other file as defined. On a dedicated server this will in most cases be the syslog. 

If you are running an enterprise setup it's good practive to pipe the error into the syslog and hook the syslog to a server monitoring tool or service instead of trying to write the errors to the apache log.

I hope that helps,

Johan

[Dmitry Rekun]

@Johan Janssens

You are not completely right. When you throw an Exception, code is not executed after. So when I throw it with the 404 code, Joomla handle this situation displaying 404 page. The response status is 404. Check it by yourself ;)

So if I get a 404 code from my Model (for example):

if (empty($data))
{
    throw new Exception(JText::_('COM_MYCOMP_ERROR_MESSAGE_NOT_FOUND'), 404);
}

then I throw an Exception in my View or Controller without any logging. If it is not the 404 code, then no special Exception is thrown and I display general error to the user and log the details. This works well in Joomla 2.5 and Joomla 3.x.

What I do not like here is that my Model is coupled to the JText. May be it is better to throw without the JText and then use it in the View (Controller). But that's the details of implementation :)

Dmitry

[Johan Janssens]

I stand corrected, missed the code part where you are re-throwing the exception as a 404. In that case Joomla will indeed show a proper 404 status response.

Few extra remarks :

1. I would be careful to only capture 404 exception code's and handle all the rest as application error messages. Application error message are intended if you know what went wrong, recovered from it and want to inform the user to take a different action. For example, after form data validation failed. 

If an unforeseen exception happens in your code, the most proper error would be a status 500 with an Jooma error page. 

2. Instead of using the base exception class, a better approach is to re-throw your exception as a named exception, for example consider using a NotFoundException() with a hardcoded code of 404. 

This way code on a higher level can capture your exception based on it's class name not it's error code. Exceptions are intended to be caught like that. The exception code is optional. 

3. About the coupling to JText. I wouldn't the responsibility of translating the exception message lies with the renderer of the message. It should be done at render time not when the exception is thrown.

Happy coding,

Johan

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! General Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-general/Z8e-GPOuXrI/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-gene...@googlegroups.com.

To post to this group, send an email to joomla-de...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/groups/opt_out.

[Dmitry Rekun]

@Johan Janssens thanks for the remarks.

1. Agree. It was just an example.

2. Good point.

3. Can you provide some kind of example based on Joomla's MVC workflow?

Dmitry

среда, 8 января 2014 г., 17:15:14 UTC+2 пользователь Johan Janssens написал:

To unsubscribe from this group and all of its topics, send an email to joomla-dev-general+unsub...@googlegroups.com.

[Johan Janssens]

About 3, this is more the responsibility of the Joomla error handler instead of the responsibility of your components. Unless you will be rendering the error page yourself.

Codewise there is a difference between Joomla 2.5 and 3.x in how uncaught exceptions are handled.

1. Joomla 3.x

In libraries/cms.php on line 33 you find the following code 

// Register a handler for uncaught exceptions that shows a pretty error page when possible

set_exception_handler(array('JErrorPage', 'render'));

Joomla is registering a custom exception handler here to render the error page. The actual handler is implemented through JErrorPage found in libraries/cms/error/page.php.

JErrorPage is responsible to create JDocumentError object to render the error. JDocumentError in return will use the error.php template to render the error. 

The actual exception being caught here is being passed all the way through to the actual template which is responsible to render the error.

Somewhere in this flow the error message should be translated using JText. Since JText is template specific the most logical place to do this would be in the error.php template. Right now the error is here outputted directly.

Example for the system template, 

<p><?php echo $this->error->getMessage(); ?></p>

Which should be

<p><?php echo JText::_($this->error->getMessage()); ?></p>

This change is fully backwards compatible and would allow developers to pass language string back instead of needing to use JText when throwing exceptions.

2. Joomla 2.5

In Joomla 2.5 the flow to catch exceptions works slightly different and is being done using a try {} catch {) block in the dispatch function 

In administrator/includes/application.php on line 130 you will find :

public function dispatch($component = null)

{

try

{

….

}

// Mop up any uncaught exceptions.

catch (Exception $e)

{

$code = $e->getCode();

JError::raiseError($code ? $code : 500, $e->getMessage());

}

}

Joomla 2.5 uses the deprecated JError::raiseError to call JError::customErrorPage() to render the error. Same logic applies here too. Slightly different API's. 

Also here the best place to put the JText call would be in the actual template rendering the error, instead of pushing the translated string through in the exception message.

Does that help ?

Johan

To unsubscribe from this group and all of its topics, send an email to joomla-dev-gene...@googlegroups.com.

[Herman Peeren]

On Wednesday, 8 January 2014 23:20:21 UTC+1, Johan Janssens wrote:

Somewhere in this flow the error message should be translated using JText. Since JText is template specific the most logical place to do this would be in the error.php template. Right now the error is here outputted directly.

JText has been removed deliberately from error messages after some discussion in March 2012.
See a.o.: https://groups.google.com/forum/#!searchin/joomla-dev-platform/jtext$20jerror/joomla-dev-platform/SJopGknhizs

• JM's concern in that thread was: Would you be kind enough to explain why we would not be able anymore to translate Errors in the CMS? As I spent countless hours implementing this in 1.6 for the sake of our International users, I would apprciate this to be discussed.
• And Andrew's answer there: What we are changing back to plain text are programmers errors (exceptions actually).  These are things like "Cannot find Controller file XYZ".  These are messages that the developer should see if they've made a mistake during development and they are an unnecessary overhead on your translators. Messages like "1 article published" (system messages) have not been changed.

For more details: see that old thread.

[Dmitry Rekun]

Thanks Herman it was interesting to read!

So basically the preferred way will be to throw a plain Exception in the Model (using code 500) then catch it in the View/Controller, log the details (for the developer) and show some general multilingual message to the user.

But what to do with the situations like "not found"? Can we consider this as Exception that should be thrown by the Model? Or data validation failure - is it Exception?

P.S.
Great discussion :) This could be a base for documentation.

Dmitry