set_error_handler

[mike]

We should be setting an error handler that will handle php errors in much the same way we handle exceptions.

re: the manual

[david]

Not sure if I agree.

1. It will always be called, even if an @unlink or so fails.
2. Why do we need it?
3. People should rather wrap their stuff into a try { } block
4. error_reporting will always be disabled on production machines anyway

[david]

error_reporting() will return 0 inside the error handling function if the line that threw the error was called with an @ in front ;)

I do agree now, by the way ;)

[mike]

I played with this idea a bit a while back. I think I came to the conclusion that it might not be such a hot idea... at least not the way I was going about it anyway. ;)

Setting this way off on the back burner unless someone else wants to pick up on it.

[david]

Not sure if we really need this. Let's think about that after 0.11.

[david]

is this obsolete?

[Felix Gilcher <mailing_lists@…>]

I think that would be a nice option - wrapping errors in exceptions, so that catchable fatal errors can actually be handled by the framework/user.

[david]

I'm not quite sure if you can properly throw an exception from a custom handler and still catch it in the calling code though. We'll have to see.

[david]

some ideas:

1. the handler reads error_reporting() and only acts on errors that would normally occur (use the second argument of set_error_handler() for this!
2. we have an AgaviPhpErrorException, maybe with subclasses for the various types (error, notice etc)
3. we'll look at $errcontext and check if there's a $this... and if yes, we grab AgaviContext? etc... then we can at least output a half-correct error format... even though that's wonky enough since there's no 100% reliable way to determine where the correct Agavi Context is, and then there's also the exec container, which is the next problem.... meh...
4. what about various display_errors/log_errors combinations?