Class ErrorException and inheritance

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Hello all,

maybe one of you can give me an answer to the following question:

Since PHP 5.3, the class \ErrorException (which extends \Exception) has
the constructor

   [  string $message
    [, long $code
     [, long $severity
      [, string $filename
       [, long $lineno
        [, Exception $previous = NULL

By default, the object $e coming up with

[1] try
[2] {
[3]    throw new ErrorException($message, $code, $severity);
[4] }
[5] catch (ErrorException $e)
[6] {
[7] }

has methods $e->getFile() and $e->getLine() which return the filename
resp. the line number where the exception was thrown.

Assume, you define a new class

SuperErrorException extends ErrorException,

the constructor of the subclass should at least contain the same
parameters, e.g.

namespace Super;
class SuperErrorException extends \ErrorException
   public function __construct
      $message  = '',
      $code     = 0,
      $severity = 0,
      $filename = NULL, (A)
      $lineno   = NULL, (B)
      Exception $previous = NULL

Here, $filename and $lineno are NULL by default to make the parameters
optional (as in ErrorException).

The problem:

[1] try
[2] {
[3]    throw new SuperErrorException($message, $code, $severity);
[4] }
[5] catch (ErrorException $e)
[6] {
[7] }

will call SuperErrorException::__construct which overwrites the defaults
for $filename and $lineno with NULL.

Replacing $filename and $lineno in (A) and (B) by __FILE__ and __LINE__
is not the solution!

What can be done to give SuperErrorException the same core functionality
as ErrorException?

Kind regards,

Re: Class ErrorException and inheritance

Quoted text here. Click to load it

As a general rule, constructors never override constructors, so the signature
of constructor of the derived class and the signature of the constructor of the
parent class are not related. In other words, if the derived class defines its
own constructor, this one can have any signature you want, the only obligation
being that it should call parent::__construct(...) if required in order to
proprly initialize the object.

And now your interesting question. I never had the need to redefine the
constructor of an exception class, as usually I simply extend ErrorException or
Exception just with a bare:

class MyException extends Exception {}

Since exceptions are just... exceptions, I neither had the need to add
other properties or special methods, so defining new exception classes
is useful only in order to cath them.

Quoted text here. Click to load it

This constructor is completely unuseful, you may simply get rid of it since all
the fields are automagically filled in when any object derived from
ErrorException is created. You can check this simply with

var_dump(new ErrorException());

But if you really want to re-define a constructor (or, more in general, if you
want to override a method) that takes a variable number of arguments, and you
want to call the parent constructor (or parent method) with the same
combination of arguments, you can do somthing like this:

function __construct()
    $args = func_get_args();
        array($this, "parent::__construct"),

But, again, in your case there is no any need to do that.

Best regards,
/_|_\  Umberto Salsi

Re: Class ErrorException and inheritance

Thanks, Umberto,

the reason why I want to derive the ErrorException class is to add two
new properties: a timestamp and the name of the method which throws the
exception. For the name of the method, I need a new parameter.
To make it simplier, I didn'nt mention this in my first posting. ;-)

I think the best way is to use the functions func_num_args() and
func_get_args() to handle the "critical" parameters $filename and $lineno.

That's not the elegant way I was looking for, but it works fine.

Kind regards,

Re: Class ErrorException and inheritance

Werner Elflein schrieb:

Quoted text here. Click to load it

For the latter, just have a look at the stack trace
($exception->getTrace()). No need for an extra parameter here.


Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!

Site Timeline