JError and JException

[elin]

There are still many places that we are using JError and JException.  After some discussion  at JAB we came up with this plan. 

We know that it is potentially a problem for developers (including CMS developer) if they are expecting JErrors and get php exceptions, so we would like in general to fix at a dot release rather than piecemeal. Even though everyone has known since 1.6 planning started that these were on their way out, we all know that people wait until the last minute to deal with things.So some will be  caught unprepared for any change.

So, the idea we came up with is this. There is an exceptions project here:

https://github.com/joomla-projects/joomla-cms/tree/feature-exceptions

and we'd encourage people to make pull requests helping to move the process along.  So if you find something, just fix and send a quick PR, or if you want to be a hero or heroine, do a search for JError and JException and do a big chunk of them. Then whatever gets done can be tested and merged into the beta of 3.2 so people have a chance to find those unexpected cases.  It would also be great to take this opportunity to write some "expected exception" test cases where we don't have them if you want real glory.. 

Really, this will help make the CMS much more modern and forward looking, we don't need to be using code designed to solve problems in PHP that are not there any more.

Elin

[El KuKu]

BIG +1 for starting this.
Expect some PRs ;)

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ove]

Is this still valid code or is there a replacement. I think it's the
only lines I still use and the core do use it. Do I need them at all?

// Check for errors.
if (count($errors = $this->get('Errors')))
{
JError::raiseError(500, implode("\n", $errors));
return false;

[El KuKu]

is this from the auth plugin ?

----
Sent from my Android =;)

On Jun 10, 2013 2:19 AM, "Ove" <tobby.e...@gmail.com> wrote:

Is this still valid code or is there a replacement. I think it's the only lines I still use and the core do use it. Do I need them at all?

        // Check for errors.
        if (count($errors = $this->get('Errors')))
        {
            JError::raiseError(500, implode("\n", $errors));
            return false;
        }


On 10.06.2013 02:56, elin wrote:

There are still many places that we are using JError and JException.  After some discussion  at JAB we came up with this plan.
We know that it is potentially a problem for developers (including CMS developer) if they are expecting JErrors and get php exceptions, so we would like in general to fix at a dot release rather than piecemeal. Even though everyone has known since 1.6 planning started that these were on their way out, we all know that people wait until the last minute to deal with things.So some will be  caught unprepared for any change.

So, the idea we came up with is this. There is an exceptions project here:

https://github.com/joomla-projects/joomla-cms/tree/feature-exceptions

and we'd encourage people to make pull requests helping to move the process along.  So if you find something, just fix and send a quick PR, or if you want to be a hero or heroine, do a search for JError and JException and do a big chunk of them. Then whatever gets done can be tested and merged into the beta of 3.2 so people have a chance to find those unexpected cases.  It would also be great to take this opportunity to write some "expected exception" test cases where we don't have them if you want real glory..

Really, this will help make the CMS much more modern and forward looking, we don't need to be using code designed to solve problems in PHP that are not there any more.

Elin
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

[El KuKu]

Some additional thoughts:

1) What do you think of creating custom exceptions for special cases? I know that this is somewhat "deprecated", but to me it does not make much sense to throw different standard exceptions and catching them all in the same place...

So I would like to propose an "AuthenticationException" that is thrown when authentication fails, and adding an exception handler that may log those events or do whatever the site admin feels appropriate.

2) There is a very interesting project (that seems to be used already by some "big players") that handles all kinds of PHP warnings, errors and exceptions and displays them in a fancy way for development, or in a "simple" way for production..

I would like to ask if someone already has experience with the script and if you think that this might be a good addition:
https://github.com/filp/whoops

[piotr_cz]

This code is currently present in every view:
https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_content/views/article/view.html.php#L49
https://github.com/joomla/joomla-cms/blob/master/components/com_content/views/article/view.html.php#L43

and every component ACL checks
https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_content/content.php


I'd keep it like this along the 3.x series, I can't see practical
advantages in removing it, but use exceptions whenever something is
built on new MVC (4.x).

On Jun 10, 8:20 pm, El KuKu <der.el.k...@gmail.com> wrote:
> is this from the auth plugin ?
>
> ----
> Sent from my Android =;)

> On Jun 10, 2013 2:19 AM, "Ove" <tobby.eriks...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Is this still valid code or is there a replacement. I think it's the only
> > lines I still use and the core do use it. Do I need them at all?
>
> >         // Check for errors.
> >         if (count($errors = $this->get('Errors')))
> >         {
> >             JError::raiseError(500, implode("\n", $errors));
> >             return false;
> >         }
>
> > On 10.06.2013 02:56, elin wrote:
>
> >> There are still many places that we are using JError and JException.
> >>  After some discussion  at JAB we came up with this plan.
> >> We know that it is potentially a problem for developers (including CMS
> >> developer) if they are expecting JErrors and get php exceptions, so we
> >> would like in general to fix at a dot release rather than piecemeal. Even
> >> though everyone has known since 1.6 planning started that these were on
> >> their way out, we all know that people wait until the last minute to deal
> >> with things.So some will be  caught unprepared for any change.
>
> >> So, the idea we came up with is this. There is an exceptions project here:
>

> >>https://github.com/joomla-**projects/joomla-cms/tree/**feature-except...<https://github.com/joomla-projects/joomla-cms/tree/feature-exceptions>

>
> >> and we'd encourage people to make pull requests helping to move the
> >> process along.  So if you find something, just fix and send a quick PR, or
> >> if you want to be a hero or heroine, do a search for JError and JException
> >> and do a big chunk of them. Then whatever gets done can be tested and
> >> merged into the beta of 3.2 so people have a chance to find those
> >> unexpected cases.  It would also be great to take this opportunity to write
> >> some "expected exception" test cases where we don't have them if you want
> >> real glory..
>
> >> Really, this will help make the CMS much more modern and forward looking,
> >> we don't need to be using code designed to solve problems in PHP that are
> >> not there any more.
>
> >> Elin
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Joomla! CMS Development" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an

> >> email to joomla-dev-cms+unsubscribe@**googlegroups.com<joomla-dev-cms%2Bunsubscribe@ googlegroups.com>
> >> .
> >> To post to this group, send an email to joomla-dev-cms@googlegroups.**com<joomla-...@googlegroups.com>
> >> .
> >> Visit this group athttp://groups.google.com/**
> >> group/joomla-dev-cms?hl=en-GB<http://groups.google.com/group/joomla-dev-cms?hl=en-GB>
> >> .
> >> For more options, visithttps://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> >> .

>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Joomla! CMS Development" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to joomla-dev-cms+unsubscribe@**googlegroups.com<joomla-dev-cms%2Bunsubscribe@ googlegroups.com>
> > .
> > To post to this group, send an email to joomla-dev-cms@googlegroups.**com<joomla-...@googlegroups.com>
> > .
> > Visit this group athttp://groups.google.com/**
> > group/joomla-dev-cms?hl=en-GB<http://groups.google.com/group/joomla-dev-cms?hl=en-GB>
> > .
> > For more options, visithttps://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> > .

[elin]

Copy an paste code can be copy and paste replaced though.  And the presence of those is keeping us from moving away from JObject in places in the core cms where it might be  possible.

 

Sometimes we can replace what is currently  an error with an enqueued message but no exception. I know there is different thinking on this but that's my preference a lot of times.

I'd like to hear people's thoughts on the custom issue.  I totally understand why the framework is using only the standard names but in the application it might make sense IF we agree on a limited set of options and are not making up new ones all the time. 

Elin