What is the best way for raising an error message in Joomla 4

Question

I'm working on updating a component for Joomla 4. In the code, there are various bits where we raise an error code when for example the user is not authorised to access a certain part. For example in pre-Joomla 4 the code we used is as follows:

JError::raiseError(403, JText::_('JERROR_ALERTNOAUTHOR'));

Looking at various coding examples, I have seen different ways of raising the error in Joomla 4.

1. $app->enqueueMessage(Text::_('JERROR_ALERTNOAUTHOR'), 'warning');
   $app->setHeader('status', 403, true);
   

   sometimes this example is without the second line in which the header is set.

2. throw new NotAllowed(Text::_('JERROR_ALERTNOAUTHOR'), 403);
   

3. Log::add(Text::_('JERROR_ALERTNOAUTHOR'), Log::ERROR, 'jerror');
   

4. throw new \Exception(Text::_('JERROR_ALERTNOAUTHOR'), 403);
   

I am interested in knowing of any other alternatives. Can anyone explain the difference between the examples I have given? What are the reasons for using one over another?

Answer 1

In #1 the first line of the first method will output a message to the next page that is displayed to user after the processing has completed so this is a nice simple way to inform that user that they have an authorisation issue, it doesn't have to be a 403. You could do more processing and provide more meaningful messages that reflect the actual access issue. For example "You need to be logged in to view this page" or "you do not have the required access level to view this page".

The second line is making the issue a Html Error 403, which is optional and not required in my view if you still have control of the processing and can provide a meaningful application related error or message. There is also a conflict between issuing a 'warn' message with a 403 which should be an 'error' in my view.

#2 example throws an exception message for a condition you are specifically looking for, a not authorised situation, and you want to stop further processing and access and produce a Html Error 403. Again if your authorisation issue is within your extension then I don't think a Html 403 error is appropriate unless you are trying to access some Html resource.

#3 writes a message to the Log defined in the extension but does not show anything to the user. You would use this is cases where you want to record particular messages for diagnosis or auditing. It could be used in addition to any of the other examples to record what is happening, but a 403 is very generic and would be better to record more diagnostic and useful details.

#4 Is another exception but for a situation that has occurred that you haven't prepared for, is unexpected, so it is a default catchall that will stop processing and in this example produce a 403 Html Error which may or may not be the correct error number to produce

I would use #1, first line at least, in most cases and in particular if you want to inform the end user of the status, (success,Info,warn,error),of processing in your code.

Next would be #2 where you want to stop processing because a condition that you have predicted might occur has been met that can't be dealt with in your code, but rarely will that be a Html 403

And then #4 would be something you would see in places where there is potential for an authorisation issue to come back that you don't know what it will be and you want to play it safe and stop processing. A call to a database or API or some other processing that happens outside of your control where you are attempting to login or provide credentials are good candidates for this type of exception that might warrant a Html 403 but you would be better off reading up on exception handling and seeing if you can trap the message coming back from the external processing and reflect that message instead of a generic 403.

#3 could be inserted before #1,#2 & #4 or after #1 if you want to record the issue.