Everything

php

PHP5: Exceptions must valid objects that are derived from class Exception?

php.internals

Erik Franzén

22 years ago

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

Markus Fischer

22 years ago

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

22 years ago

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

22 years ago

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 Börger

22 years ago

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

22 years ago

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