FAQ
Edit report at http://pear.php.net/bugs/bug.php?id=18401&edit=1

ID: 18401
Updated by: php@mamasam.net
Reported By: daniel dot oconnor at gmail dot com
Summary: Consider swapping to exceptions, not trigger_error
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package: HTML_QuickForm2
Package Version: 0.5.0
PHP Version: Irrelevant
Roadmap Versions:
New Comment:

-Status: Open
+Status: Bogus
Thank you for taking the time to write to us, but this is not
a bug.

Calling an undefined method is an error in your code and it should be
handled as such. If we throw an exception instead, ok you get a nice
backtrace with it, but exceptions are made to be caught, I see no reason
why you would want to catch an undefined method exception because it's
obviously an error in your code. There are different ways to handle user
errors, you can write your own error handler that will convert user
errors to exceptions if you need a backtrace, or simply use an error
handler that prints a backtrace. A lot of other projects do it like us
(even MDB2).


Previous Comments:
------------------------------------------------------------------------

[2011-03-27 07:12:03] doconnor

Description:
------------
In HTML_QuickForm2_Container::__call(), trigger error is
used.

http://svn.php.net/viewvc/pear/packages/HTML_QuickForm2/t
runk/HTML/QuickForm2/Container.php?view=markup#l432

If you manage to trigger said error, you get a fatal error
about an undefined method (good); which points you at the
trigger_error() method in __call() - not so helpful.

Without an extension like xdebug; it becomes tricky for you
to work out where you made the mistake; and it looks like a
fault of HTML_Quickform2_Container

An exception or trigger_error working out where it was called
from via debug_backtrace() would be much more helpful.

Test script:
---------------
<?php
require_once 'HTML/QuickForm2.php';

$form = new HTML_QuickForm2();
$form->toArray(); // an unported quickform 1 method

Expected result:
----------------
An exception or fatal error which points at line 3.

Actual result:
--------------
A fatal error along the lines of
Cannot call undefined method HTML_QuickForm2::toArray()
called from HTML_QuickForm2_Container; line 443

(which is misleading)

------------------------------------------------------------------------

Search Discussions

  • Daniel Oconnor at Mar 27, 2011 at 8:09 am
    Edit report at http://pear.php.net/bugs/bug.php?id=18401&edit=1

    ID: 18401
    Updated by: daniel.oconnor@gmail.com
    Reported By: daniel dot oconnor at gmail dot com
    Summary: Consider swapping to exceptions, not trigger_error
    Status: Bogus
    Type: Feature/Change Request
    Package: HTML_QuickForm2
    Package Version: 0.5.0
    PHP Version: Irrelevant
    Roadmap Versions:
    New Comment:

    The point is that it's not actually obviously an error in my code: the
    generated error
    message looks like an internal HTML_Quickform2 error; as it lacks info
    on where
    __call was invoked from.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-03-27 08:54:09] mansion

    -Status: Open
    +Status: Bogus
    Thank you for taking the time to write to us, but this is not
    a bug.

    Calling an undefined method is an error in your code and it should be
    handled as such. If we throw an exception instead, ok you get a nice
    backtrace with it, but exceptions are made to be caught, I see no reason
    why you would want to catch an undefined method exception because it's
    obviously an error in your code. There are different ways to handle user
    errors, you can write your own error handler that will convert user
    errors to exceptions if you need a backtrace, or simply use an error
    handler that prints a backtrace. A lot of other projects do it like us
    (even MDB2).

    ------------------------------------------------------------------------

    [2011-03-27 07:12:03] doconnor

    Description:
    ------------
    In HTML_QuickForm2_Container::__call(), trigger error is
    used.

    http://svn.php.net/viewvc/pear/packages/HTML_QuickForm2/t
    runk/HTML/QuickForm2/Container.php?view=markup#l432

    If you manage to trigger said error, you get a fatal error
    about an undefined method (good); which points you at the
    trigger_error() method in __call() - not so helpful.

    Without an extension like xdebug; it becomes tricky for you
    to work out where you made the mistake; and it looks like a
    fault of HTML_Quickform2_Container

    An exception or trigger_error working out where it was called
    from via debug_backtrace() would be much more helpful.

    Test script:
    ---------------
    <?php
    require_once 'HTML/QuickForm2.php';

    $form = new HTML_QuickForm2();
    $form->toArray(); // an unported quickform 1 method

    Expected result:
    ----------------
    An exception or fatal error which points at line 3.

    Actual result:
    --------------
    A fatal error along the lines of
    Cannot call undefined method HTML_QuickForm2::toArray()
    called from HTML_QuickForm2_Container; line 443

    (which is misleading)

    ------------------------------------------------------------------------
  • Php at Mar 27, 2011 at 10:31 am
    Edit report at http://pear.php.net/bugs/bug.php?id=18401&edit=1

    ID: 18401
    Updated by: php@mamasam.net
    Reported By: daniel dot oconnor at gmail dot com
    Summary: Consider swapping to exceptions, not trigger_error
    Status: Bogus
    Type: Feature/Change Request
    Package: HTML_QuickForm2
    Package Version: 0.5.0
    PHP Version: Irrelevant
    Roadmap Versions:
    New Comment:

    I consider calling toArray() on a class that don't have this method
    defined, an error in your code. I also agree that not having the correct
    line and file information in the original error report is annoying, but
    there are ways to get the backtrace (xdebug does it for you by default
    for example), so this is a minor annoyance, usually you know where the
    call to toArray() was done in your code.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-03-27 09:12:10] doconnor

    The point is that it's not actually obviously an error in my code: the
    generated error
    message looks like an internal HTML_Quickform2 error; as it lacks info
    on where
    __call was invoked from.

    ------------------------------------------------------------------------

    [2011-03-27 08:54:09] mansion

    -Status: Open
    +Status: Bogus
    Thank you for taking the time to write to us, but this is not
    a bug.

    Calling an undefined method is an error in your code and it should be
    handled as such. If we throw an exception instead, ok you get a nice
    backtrace with it, but exceptions are made to be caught, I see no reason
    why you would want to catch an undefined method exception because it's
    obviously an error in your code. There are different ways to handle user
    errors, you can write your own error handler that will convert user
    errors to exceptions if you need a backtrace, or simply use an error
    handler that prints a backtrace. A lot of other projects do it like us
    (even MDB2).

    ------------------------------------------------------------------------

    [2011-03-27 07:12:03] doconnor

    Description:
    ------------
    In HTML_QuickForm2_Container::__call(), trigger error is
    used.

    http://svn.php.net/viewvc/pear/packages/HTML_QuickForm2/t
    runk/HTML/QuickForm2/Container.php?view=markup#l432

    If you manage to trigger said error, you get a fatal error
    about an undefined method (good); which points you at the
    trigger_error() method in __call() - not so helpful.

    Without an extension like xdebug; it becomes tricky for you
    to work out where you made the mistake; and it looks like a
    fault of HTML_Quickform2_Container

    An exception or trigger_error working out where it was called
    from via debug_backtrace() would be much more helpful.

    Test script:
    ---------------
    <?php
    require_once 'HTML/QuickForm2.php';

    $form = new HTML_QuickForm2();
    $form->toArray(); // an unported quickform 1 method

    Expected result:
    ----------------
    An exception or fatal error which points at line 3.

    Actual result:
    --------------
    A fatal error along the lines of
    Cannot call undefined method HTML_QuickForm2::toArray()
    called from HTML_QuickForm2_Container; line 443

    (which is misleading)

    ------------------------------------------------------------------------
  • Helgith at Mar 27, 2011 at 1:52 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=18401&edit=1

    ID: 18401
    Updated by: helgith@gmail.com
    Reported By: daniel dot oconnor at gmail dot com
    Summary: Consider swapping to exceptions, not trigger_error
    Status: Bogus
    Type: Feature/Change Request
    Package: HTML_QuickForm2
    Package Version: 0.5.0
    PHP Version: Irrelevant
    Roadmap Versions:
    New Comment:

    A side note, referencing how MDB2 does it (among other things) seems a
    bit faulty;
    MDB2 is a PHP 4 package and does things the way it does because it
    couldn't make
    use of PHP 5 features.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-03-27 11:33:41] mansion

    I consider calling toArray() on a class that don't have this method
    defined, an error in your code. I also agree that not having the correct
    line and file information in the original error report is annoying, but
    there are ways to get the backtrace (xdebug does it for you by default
    for example), so this is a minor annoyance, usually you know where the
    call to toArray() was done in your code.

    ------------------------------------------------------------------------

    [2011-03-27 09:12:10] doconnor

    The point is that it's not actually obviously an error in my code: the
    generated error
    message looks like an internal HTML_Quickform2 error; as it lacks info
    on where
    __call was invoked from.

    ------------------------------------------------------------------------

    [2011-03-27 08:54:09] mansion

    -Status: Open
    +Status: Bogus
    Thank you for taking the time to write to us, but this is not
    a bug.

    Calling an undefined method is an error in your code and it should be
    handled as such. If we throw an exception instead, ok you get a nice
    backtrace with it, but exceptions are made to be caught, I see no reason
    why you would want to catch an undefined method exception because it's
    obviously an error in your code. There are different ways to handle user
    errors, you can write your own error handler that will convert user
    errors to exceptions if you need a backtrace, or simply use an error
    handler that prints a backtrace. A lot of other projects do it like us
    (even MDB2).

    ------------------------------------------------------------------------

    [2011-03-27 07:12:03] doconnor

    Description:
    ------------
    In HTML_QuickForm2_Container::__call(), trigger error is
    used.

    http://svn.php.net/viewvc/pear/packages/HTML_QuickForm2/t
    runk/HTML/QuickForm2/Container.php?view=markup#l432

    If you manage to trigger said error, you get a fatal error
    about an undefined method (good); which points you at the
    trigger_error() method in __call() - not so helpful.

    Without an extension like xdebug; it becomes tricky for you
    to work out where you made the mistake; and it looks like a
    fault of HTML_Quickform2_Container

    An exception or trigger_error working out where it was called
    from via debug_backtrace() would be much more helpful.

    Test script:
    ---------------
    <?php
    require_once 'HTML/QuickForm2.php';

    $form = new HTML_QuickForm2();
    $form->toArray(); // an unported quickform 1 method

    Expected result:
    ----------------
    An exception or fatal error which points at line 3.

    Actual result:
    --------------
    A fatal error along the lines of
    Cannot call undefined method HTML_QuickForm2::toArray()
    called from HTML_QuickForm2_Container; line 443

    (which is misleading)

    ------------------------------------------------------------------------
  • Php at Mar 27, 2011 at 2:12 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=18401&edit=1

    ID: 18401
    Updated by: php@mamasam.net
    Reported By: daniel dot oconnor at gmail dot com
    Summary: Consider swapping to exceptions, not trigger_error
    Status: Bogus
    Type: Feature/Change Request
    Package: HTML_QuickForm2
    Package Version: 0.5.0
    PHP Version: Irrelevant
    Roadmap Versions:
    New Comment:

    The question is: what is the expected behavior when you call a non
    existent method on an object ? This is not said in the PHP manual, but
    there is what I consider a hint in the documentation of the __get()
    method. What if we do the same and use the backtrace to get correct
    information about where the error happened first ?

    http://www.php.net/manual/en/language.oop5.overloading.php


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-03-27 14:54:18] dufuz

    A side note, referencing how MDB2 does it (among other things) seems a
    bit faulty;
    MDB2 is a PHP 4 package and does things the way it does because it
    couldn't make
    use of PHP 5 features.

    ------------------------------------------------------------------------

    [2011-03-27 11:33:41] mansion

    I consider calling toArray() on a class that don't have this method
    defined, an error in your code. I also agree that not having the correct
    line and file information in the original error report is annoying, but
    there are ways to get the backtrace (xdebug does it for you by default
    for example), so this is a minor annoyance, usually you know where the
    call to toArray() was done in your code.

    ------------------------------------------------------------------------

    [2011-03-27 09:12:10] doconnor

    The point is that it's not actually obviously an error in my code: the
    generated error
    message looks like an internal HTML_Quickform2 error; as it lacks info
    on where
    __call was invoked from.

    ------------------------------------------------------------------------

    [2011-03-27 08:54:09] mansion

    -Status: Open
    +Status: Bogus
    Thank you for taking the time to write to us, but this is not
    a bug.

    Calling an undefined method is an error in your code and it should be
    handled as such. If we throw an exception instead, ok you get a nice
    backtrace with it, but exceptions are made to be caught, I see no reason
    why you would want to catch an undefined method exception because it's
    obviously an error in your code. There are different ways to handle user
    errors, you can write your own error handler that will convert user
    errors to exceptions if you need a backtrace, or simply use an error
    handler that prints a backtrace. A lot of other projects do it like us
    (even MDB2).

    ------------------------------------------------------------------------

    [2011-03-27 07:12:03] doconnor

    Description:
    ------------
    In HTML_QuickForm2_Container::__call(), trigger error is
    used.

    http://svn.php.net/viewvc/pear/packages/HTML_QuickForm2/t
    runk/HTML/QuickForm2/Container.php?view=markup#l432

    If you manage to trigger said error, you get a fatal error
    about an undefined method (good); which points you at the
    trigger_error() method in __call() - not so helpful.

    Without an extension like xdebug; it becomes tricky for you
    to work out where you made the mistake; and it looks like a
    fault of HTML_Quickform2_Container

    An exception or trigger_error working out where it was called
    from via debug_backtrace() would be much more helpful.

    Test script:
    ---------------
    <?php
    require_once 'HTML/QuickForm2.php';

    $form = new HTML_QuickForm2();
    $form->toArray(); // an unported quickform 1 method

    Expected result:
    ----------------
    An exception or fatal error which points at line 3.

    Actual result:
    --------------
    A fatal error along the lines of
    Cannot call undefined method HTML_QuickForm2::toArray()
    called from HTML_QuickForm2_Container; line 443

    (which is misleading)

    ------------------------------------------------------------------------
  • Helgith at Mar 27, 2011 at 3:50 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=18401&edit=1

    ID: 18401
    Updated by: helgith@gmail.com
    Reported By: daniel dot oconnor at gmail dot com
    Summary: Consider swapping to exceptions, not trigger_error
    Status: Bogus
    Type: Feature/Change Request
    Package: HTML_QuickForm2
    Package Version: 0.5.0
    PHP Version: Irrelevant
    Roadmap Versions:
    New Comment:

    I agree, the manual isn't very clear but we need to consider that __get
    and __call
    are inherently different. I would fully expect a notice from __get
    failing because
    that's what happens when I do the same thing on array keys that don't
    exist, where
    as when I call a method that does not exist PHP gives me a fatal error.

    If you want to insist on using trigger_error then I recommend a proper
    PHP Fatal as
    I'm calling a function which does no longer exists, just to stay in line
    with what PHP
    does - Notice is more of a "hey, something is wrong but we can let it
    slide because
    everything else can continue running in theory".

    If you feel like you want to use an exception, perhaps have a look at
    using either
    of these built in ones:

    http://php.net/manual/en/class.badmethodcallexception.php
    http://php.net/manual/en/class.badfunctioncallexception.php

    What do you guys think of either one of those solutions? I'm thinking
    this from the
    perspective of other packages as well, in case they encountered a
    similar situation
    :)


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-03-27 15:14:45] mansion

    The question is: what is the expected behavior when you call a non
    existent method on an object ? This is not said in the PHP manual, but
    there is what I consider a hint in the documentation of the __get()
    method. What if we do the same and use the backtrace to get correct
    information about where the error happened first ?

    http://www.php.net/manual/en/language.oop5.overloading.php

    ------------------------------------------------------------------------

    [2011-03-27 14:54:18] dufuz

    A side note, referencing how MDB2 does it (among other things) seems a
    bit faulty;
    MDB2 is a PHP 4 package and does things the way it does because it
    couldn't make
    use of PHP 5 features.

    ------------------------------------------------------------------------

    [2011-03-27 11:33:41] mansion

    I consider calling toArray() on a class that don't have this method
    defined, an error in your code. I also agree that not having the correct
    line and file information in the original error report is annoying, but
    there are ways to get the backtrace (xdebug does it for you by default
    for example), so this is a minor annoyance, usually you know where the
    call to toArray() was done in your code.

    ------------------------------------------------------------------------

    [2011-03-27 09:12:10] doconnor

    The point is that it's not actually obviously an error in my code: the
    generated error
    message looks like an internal HTML_Quickform2 error; as it lacks info
    on where
    __call was invoked from.

    ------------------------------------------------------------------------

    [2011-03-27 08:54:09] mansion

    -Status: Open
    +Status: Bogus
    Thank you for taking the time to write to us, but this is not
    a bug.

    Calling an undefined method is an error in your code and it should be
    handled as such. If we throw an exception instead, ok you get a nice
    backtrace with it, but exceptions are made to be caught, I see no reason
    why you would want to catch an undefined method exception because it's
    obviously an error in your code. There are different ways to handle user
    errors, you can write your own error handler that will convert user
    errors to exceptions if you need a backtrace, or simply use an error
    handler that prints a backtrace. A lot of other projects do it like us
    (even MDB2).

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=18401
  • Php at Mar 27, 2011 at 7:57 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=18401&edit=1

    ID: 18401
    Updated by: php@mamasam.net
    Reported By: daniel dot oconnor at gmail dot com
    Summary: Consider swapping to exceptions, not trigger_error
    Status: Bogus
    Type: Feature/Change Request
    Package: HTML_QuickForm2
    Package Version: 0.5.0
    PHP Version: Irrelevant
    Roadmap Versions:
    New Comment:

    We already trigger a E_USER_ERROR, which is a fatal error, not a
    notice.
    The SPL exceptions don't extend PEAR Exception.
    So I think we keep it like it is and use the backtrace to set more
    precisely where the error happened first, as shown in the PHP manual
    example for __get().


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-03-27 16:52:45] dufuz

    I agree, the manual isn't very clear but we need to consider that __get
    and __call
    are inherently different. I would fully expect a notice from __get
    failing because
    that's what happens when I do the same thing on array keys that don't
    exist, where
    as when I call a method that does not exist PHP gives me a fatal error.

    If you want to insist on using trigger_error then I recommend a proper
    PHP Fatal as
    I'm calling a function which does no longer exists, just to stay in line
    with what PHP
    does - Notice is more of a "hey, something is wrong but we can let it
    slide because
    everything else can continue running in theory".

    If you feel like you want to use an exception, perhaps have a look at
    using either
    of these built in ones:

    http://php.net/manual/en/class.badmethodcallexception.php
    http://php.net/manual/en/class.badfunctioncallexception.php

    What do you guys think of either one of those solutions? I'm thinking
    this from the
    perspective of other packages as well, in case they encountered a
    similar situation
    :)

    ------------------------------------------------------------------------

    [2011-03-27 15:14:45] mansion

    The question is: what is the expected behavior when you call a non
    existent method on an object ? This is not said in the PHP manual, but
    there is what I consider a hint in the documentation of the __get()
    method. What if we do the same and use the backtrace to get correct
    information about where the error happened first ?

    http://www.php.net/manual/en/language.oop5.overloading.php

    ------------------------------------------------------------------------

    [2011-03-27 14:54:18] dufuz

    A side note, referencing how MDB2 does it (among other things) seems a
    bit faulty;
    MDB2 is a PHP 4 package and does things the way it does because it
    couldn't make
    use of PHP 5 features.

    ------------------------------------------------------------------------

    [2011-03-27 11:33:41] mansion

    I consider calling toArray() on a class that don't have this method
    defined, an error in your code. I also agree that not having the correct
    line and file information in the original error report is annoying, but
    there are ways to get the backtrace (xdebug does it for you by default
    for example), so this is a minor annoyance, usually you know where the
    call to toArray() was done in your code.

    ------------------------------------------------------------------------

    [2011-03-27 09:12:10] doconnor

    The point is that it's not actually obviously an error in my code: the
    generated error
    message looks like an internal HTML_Quickform2 error; as it lacks info
    on where
    __call was invoked from.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=18401

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
categoriesphp
postedMar 27, '11 at 7:51a
activeMar 27, '11 at 7:57p
posts7
users3
websitepear.php.net

3 users in discussion

Php: 4 posts Helgith: 2 posts Daniel Oconnor: 1 post

People

Translate

site design / logo © 2022 Grokbase