Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

set_exception_handler invokes the handler but still show the fatal error msg #3019

Closed
ghost opened this issue Jun 23, 2014 · 9 comments
Closed

Comments

@ghost
Copy link

ghost commented Jun 23, 2014

The following code should print Only print this message: User message here.

set_exception_handler(function($e) {
    echo "Only print this message: " . $e->getMessage();
});

throw new Exception("User message here.");

But instead it produces

Fatal error: Uncaught exception 'Exception' with message 'User message here.' in test.php:7
Stack trace:
#0 {main}
Only print this message: User message here.
@milo
Copy link

milo commented Sep 4, 2014

This behaviour can be disabled by hhvm.log.always_log_unhandled_exceptions=false.

@paulbiss
Copy link
Contributor

paulbiss commented Sep 9, 2014

@milo is correct

$ hhvm -vLog.AlwaysLogUnhandledExceptions=false test.php
Only print this message: User message here.
$

@paulbiss paulbiss closed this as completed Sep 9, 2014
@SiebelsTim
Copy link
Contributor

@paulbiss This is a workaround and no fix, isn't it?

@paulbiss
Copy link
Contributor

paulbiss commented Sep 9, 2014

Should the trace always be suppressed when an exception handler is defined?

@paulbiss paulbiss reopened this Sep 9, 2014
@SiebelsTim
Copy link
Contributor

@paulbiss Well it isn't an uncaught exception. set_exception_handler is supposed to mimic a catch I think.

@paulbiss
Copy link
Contributor

I dug into this today, we only check AlwaysLogUnhandledExceptions in two places and it's precisely to define this behavior. It seems to me that the intent here is to treat exceptions that arrive at the exception_handler this way unless the flag is set to false.

If you think we should choose a different default feel free to open another issue, but insofar as I can tell this is by design, the flag is there if you want parity with PHP5.

@Majkl578
Copy link
Contributor

@paulbiss: Maybe it should be off by default to match PHP?

@paulbiss
Copy link
Contributor

@Majkl578 we'd consider a pull request for it. You'll probably have to add ini settings for tests we have that assume it's on and we'll need to update our configs internally.

@Majkl578
Copy link
Contributor

@paulbiss: Let's have some compatibility fun. :) #4066 (D26997)

hhvm-bot pushed a commit that referenced this issue Oct 30, 2014
…bleHipHopSyntax

Summary: By turning these off by default, we should match Zend behavior better on fatals with custom error handlers.

Few examples:
```
set_error_handler(function () { echo 'hello'; });
invalid();
```
This should produce only a fatal error message without calling user handler.

```
set_error_handler(function () { echo 'hello'; });
echo $invalid;
```
This should call user handler without producing notice message.

```
set_exception_handler(function () { echo 'hello'; });
throw new Exception();
```
This should call user handler without producing fatal error message.

Relates to #3019 and #4055.
Closes #4066

Reviewed By: @ptarjan

Differential Revision: D1640294

Signature: t1:1640294:1414638838:69aa654fbc4b805b3f1731d786a4e0ad338d29aa
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants