FAQ
I am prototyping on a PHP5 application using PEAR and I ran into a
strange error.

if (PEAR::isError($mReturn)) {
throw $mReturn;
}

PEAR is not configured to return exceptions instead of PEAR Errors and
the above code will generate the following error if $mReturn is a PEAR
Error.

PHP Fatal error: Exceptions must valid objects that are derived from
class Exception in E:\PHPSource\PHPFTP\Source\include\\db.inc.php on
line 226

Why must I use the built in exception class? The explantion in release
notes for PHPb4 is that it allows a general catch(Exception $e)
statement to catch all exceptions.

Isn't that up to the developer to deal with it?

/Erik

Search Discussions

  • Markus Fischer at Feb 22, 2004 at 2:56 pm

    On Sun, Feb 22, 2004 at 03:36:49PM +0100, Erik Franzén wrote :
    I am prototyping on a PHP5 application using PEAR and I ran into a
    strange error.

    if (PEAR::isError($mReturn)) {
    throw $mReturn;
    }

    PEAR is not configured to return exceptions instead of PEAR Errors and
    the above code will generate the following error if $mReturn is a PEAR
    Error.

    PHP Fatal error: Exceptions must valid objects that are derived from
    class Exception in E:\PHPSource\PHPFTP\Source\include\\db.inc.php on
    line 226

    Why must I use the built in exception class? The explantion in release
    notes for PHPb4 is that it allows a general catch(Exception $e)
    statement to catch all exceptions.

    Isn't that up to the developer to deal with it?
    The catch-all helps catching any type of exception, _given that_ it
    is derived from class Exception. The motivation behind it, and this
    makes sense to me, I'm pro this behaviour, is, that this way the
    interface of the Exception class is well defined. You can always
    count that you have the methods getMessage, getCode, getFile,
    getTraceAsString, etc. Which is IMO good.

    - Markus
  • Erik Franzén at Feb 22, 2004 at 4:45 pm

    Markus Fischer wrote:
    The catch-all helps catching any type of exception, _given that_ it
    is derived from class Exception. The motivation behind it, and this
    makes sense to me, I'm pro this behaviour, is, that this way the
    interface of the Exception class is well defined. You can always
    count that you have the methods getMessage, getCode, getFile,
    getTraceAsString, etc. Which is IMO good.

    - Markus
    With this behavior you force the developer to use the exception class.
    You cannot use your own class because PHP will trigger an error if you do.

    However, you can of course extend the exception class with your own
    class, but you cannot replace the default methods (getMessage etc) since
    they are final.

    I don't like this, since you are forced to use the built in exception
    class which also has final methods. Where has the feeling of freedom gone?

    /Erik
  • Derick Rethans at Feb 22, 2004 at 5:03 pm

    On Sun, 22 Feb 2004, [ISO-8859-1] Erik Franzén wrote:

    With this behavior you force the developer to use the exception class.
    You cannot use your own class because PHP will trigger an error if you do.

    However, you can of course extend the exception class with your own
    class, but you cannot replace the default methods (getMessage etc) since
    they are final.

    I don't like this, since you are forced to use the built in exception
    class which also has final methods. Where has the feeling of freedom gone?
    Freedom goes with functionality ;-) but I think it's indeed not wise to
    have getMessage defined as final. (I don't think it makes sense for the
    other methods to be overridden though).

    Derick
  • Marcus Boerger at Feb 22, 2004 at 6:41 pm
    Hello Derick,

    Sunday, February 22, 2004, 6:03:28 PM, you wrote:
    On Sun, 22 Feb 2004, [ISO-8859-1] Erik Franzén wrote:

    With this behavior you force the developer to use the exception class.
    You cannot use your own class because PHP will trigger an error if you do.

    However, you can of course extend the exception class with your own
    class, but you cannot replace the default methods (getMessage etc) since
    they are final.

    I don't like this, since you are forced to use the built in exception
    class which also has final methods. Where has the feeling of freedom gone?
    Freedom goes with functionality ;-) but I think it's indeed not wise to
    have getMessage defined as final. (I don't think it makes sense for the
    other methods to be overridden though).
    As i said several times, getMessage() is only a "final read only" access
    method to the private message property. Overload __toString() if you feel
    to.

    marcus
  • Markus Fischer at Feb 22, 2004 at 6:08 pm

    On Sun, Feb 22, 2004 at 05:44:43PM +0100, Erik Franzén wrote :
    Markus Fischer wrote:
    The catch-all helps catching any type of exception, _given that_ it
    is derived from class Exception. The motivation behind it, and this
    makes sense to me, I'm pro this behaviour, is, that this way the
    interface of the Exception class is well defined. You can always
    count that you have the methods getMessage, getCode, getFile,
    getTraceAsString, etc. Which is IMO good.

    - Markus
    With this behavior you force the developer to use the exception class.
    You cannot use your own class because PHP will trigger an error if you do.

    However, you can of course extend the exception class with your own
    class, but you cannot replace the default methods (getMessage etc) since
    they are final.

    I don't like this, since you are forced to use the built in exception
    class which also has final methods. Where has the feeling of freedom gone?
    Your point is true. Why getMessage() is final I don't know. My
    development with PHP5 has only started a month ago, but yet haven't
    run in any limitations by this although I'm making heavy use of
    Exceptions and Object-Code.

    - Markus

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedFeb 22, '04 at 2:37p
activeFeb 22, '04 at 6:41p
posts6
users4
websitephp.net

People

Translate

site design / logo © 2019 Grokbase