Extend ErrorException to carry $errcontext provided by PHP to the errorHander.

[glennpratt]

[glennpratt]

Fixed the notice, tests pass now.

I had error_reporting set to default on my machine, which is why they passed for me, might want to set that in bootstrap.

[makasim]

I had error_reporting set to default on my machine, which is why they passed for me, might want to set that in bootstrap.

yes, please add that.

[makasim]

I just thought of usecase. Can you give a real life example where it could be helpful.

[glennpratt]

A real life use case can be seen in Drupal 6, which I was implementing this in. The $context is used to determine if there was an error in a database API function, and if so, print and error message with the caller of the database function, instead of the database function itself.

There are certainly more elegant ways to do this in OO code, but it's there none-the-less.

http://drupalcontrib.org/api/drupal/drupal%21includes%21common.inc/function/drupal_error_handler/6

[makasim]

honestly I dont like the prefix UniversalErrorCatcher_ before Exception classes. Also the context usage is more drupal special case and I dont see other ways to use it. So what I can propose to go forward:

• create setErrorExceptionClass($class), setSuppressedErrorExceptionClass($class), setFatalErrorExceptionClass($class).
• pass the context as the last constructor argument. It would do nothing with default classes but allows a developer to set the exception class which supports that.
• the settters should checkes whether given parameter is string and in instanceof ErrorException class.

@vatson ping

[glennpratt]

ErrorException has a sixth argument which is the previous Exception. I thought about passing it NULL then adding a seventh, but that seems messy.

[glennpratt]

I do see the usage is limited, but I think it's a fairly minimal burden to allow the callback to wire up to any error handler previously registered to set_error_handler.

Unless there is an opportunity to manipulate the actual exception construction (probably by isolating that task to methods and extending) I don't see much need to change the exception class, especially if it's already carrying everything a PHP error_handler receives.

BTW, you could have short exception names for users try/catch blocks and the callback while maintaining PEAR/PSR-0 compliant structure for everything else. Create empty interfaces with your short names and stash them in the implementation files.

[makasim]

I've got your point. so let create protected:

• createErrorException()
• createSuppressedErrorException()
• createFatalErrorException()

methods. sure with context as last parameter. so you can overwrite it.

BTW, you could have short exception names for users try/catch blocks and the callback while maintaining PEAR/PSR-0 compliant structure for everything else. Create empty interfaces with your short names and stash them in the implementation files.

sorry dont understand. could you give an example?

[makasim]

those the methods will add one more level to stack trace:

Catcher::createErrorHandler
Catcher::handleError
...

from this point of view exception class configuration is better.

[glennpratt]

Regarding the Exceptions names, I was saying if you want a short name for users to catch, you could do that with an interface and have everything else follow class naming conventions:

<?php
interface SuppressedErrorException {}

class UniversalErrorCatcher_SuppressedErrorException
    extends UniversalErrorCatcher_ErrorException
    implements SuppressedErrorException {}

[makasim]

Regarding the Exceptions names, I was saying if you want a short name for users to catch, you could do that with an interface and have everything else follow class naming conventions:

I dont mind to add Interface post fix. What do you think?

SuppressedErrorExceptionInterface

[glennpratt]

Sounds good, totally another issue.

[makasim]

Sounds good, totally another issue.

maybe in this case the lib could provide:

• ExceptionInterface
• ErrorExceptionInterface
• SuppressedErrorExceptionItnerface
• FatalErrorExceptionInterface

?

[vatson]

BTW, you could have short exception names for users try/catch blocks and the callback while maintaining PEAR/PSR-0 compliant structure for everything else. Create empty interfaces with your short names and stash them in the implementation files.

I want to note that it is contrary to PSR-0 and PSR-1:

Namespaces and classes MUST follow PSR-0. This means each class is in a file by itself, and is in a namespace of at least one level: a top-level vendor name.

Look at https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md (section 3. Namespace and Class Names)