How do we want to handle the (graceful?) removal of JError?

[Louis Landry]

Hi guys and gals,

I'd like to get some input from you all on what may be a someone sensitive topic to some.  To put it bluntly JError is a marked man.  His time has come and gone once already, but he was given a stay of execution.  Originally we had JError marked deprecated for removal in the 12.1 release.  After some intense conversations we decided to push removal out to the 13.1 release.   

In the meantime several things were marked deprecated for removal in 12.3.  Some of those things were the `JObject::getError()` family of methods.  I've given them a similar extension to the 13.1 release because we need to figure out how we are going to do this change.

Essentially what we have are a number of classes and methods in the platform that do things like:

```

if ($expression == false)

{

    $this->setError('My error message is foo.');

    return false;

}

```

The JTable classes are infamous for this sort of activity.  What needs to happen is that all of those things need to get translated into messages being queued, exceptions being thrown, etc.  I count 162 matches on `->setError(` in the platform libraries right now.  In reality that isn't a whole lot to deal with, but we need to agree upon the how and we need a few people to help us get the work done once we've decided upon the how.

So.... how do we want to handle this thing?

- Louis

[Mark Dexter]

I suppose it is not possible to do some magic for b/c purposes and
convert calls to JError into exceptions or messages in the queue? I
don't think fixing this in core will be difficult, but it seems like
it might create major b/c issues. Mark

[Elin Waring]

I've been puzzling over those setErrors for a while when I come across them (and never have been able to get a consensus answer by asking people what to do with them).  Overall I think a lot of the things that should  be exceptions have already started down that path should just finish that   journey by turning into logged messages and leaving it to the application to add a message if it makes sense. But there are a some places where the message queue makes sense especially when they are closer to the user.  

Is there any news from the PWG that is supposed to be working on the message queueing? I think consideration of that has to be part of the discussion.

Elin

[Chris Davenport]

If you mean this PWG: http://docs.joomla.org/Message_Queue_Working_Group then that's a completely different kind of message queue that is not at all related to the $app->enqueueMessage() kind of message queue.

Chris.

--
Chris Davenport
Joomla Production Leadership Team

[Andrew Eddie]

I think we can do all this with minimal backward compatibility
(depending on how you define it), or none at all. The issue boils
down to extension developers writing dual-version 2.5+3.x code. The
main issue is handling exceptions in 3.x and JError in 2.5, which is
exactly the same problem we have here (getting developers to handle
more exceptions).

So, thinking out loud, I think getError method could change to just
return false; getErrors method could change to return an empty array;
and setError could change to throw an exception. Because dual-version
developers already have to cope with exceptions from 3.x, it should
impact minimally. Obviously 3.1 (I expect) developers will have some
slight issues because JError::* disappears but they can make the
appropriate changes now, in 3.0 land, to prepare for that. Anyone that
has an iPhone sees the same sort of things in the App store (Minor
update for iOS6/iPhone 5 compatibility) so it's not an unreasonable
expectation to have of developers.

Regards,
Andrew Eddie

[Elin Waring]

That's the problem of kind of having a vague memory of something ...