Trigger E_USER_ERROR on unhandled exceptions

[WyriHaximus]

Largely based on @clue's work at clue-labs@0feb517 to trigger an error when a rejected promise hasn't been handled.

Closes #87

[jsor]

Rejections in done() are also unhandled rejections and should probably use the same error message format.

promise/src/Internal/FulfilledPromise.php

Line 54 in 57d86e5

return fatalError($exception);

https://github.com/reactphp/promise/blob/master/src/Internal/RejectedPromise.php#L45

https://github.com/reactphp/promise/blob/master/src/Internal/RejectedPromise.php#L55

Maybe we can rename fatalError() to something like unhandledRejectionError() and generate the message there.

[clue]

@WyriHaximus Thanks for looking into this again! I agree that any unhandled exceptions should cause the program to report a hard error and then die().

This is definitely a BC break, so this PR only targets the upcoming Promise v3 release branch. Once we can come up with decent solution, we should look into providing a better upgrade path for the Promise v2 release branch, e.g. printing a soft warning possibly with an option to turn this off etc.

Note that the error handler passed to set_error_handler() may silently discard the error and not die() internally. It's my understanding we should explicitly die() in this case:

https://3v4l.org/9J9TB

I also don't feel the global error handler is the best place to deal with unhandled rejections. I think the global exception handler might be a better place, but it looks like there's no (sane) way to explicitly call this handler. Here are some of my experiments:

https://3v4l.org/ktOfm

[WyriHaximus]

@clue updated this PR to match your latest experiment /cc @jsor

[WyriHaximus]

As discussed with @clue, adding a test case to spawn a child process, force it to have an unhandled rejected promise and expect a 255 exit code.

[WyriHaximus]

@clue @jsor test added

[WyriHaximus]

Had a long chat with @clue about this today. And we came to the conclusion that killing off the process in 3.0 is to soon. It would mean a hard migration, and while we will have our own projects ready by then, the ecosystem might be caught off guard by it.

What we want to do instead, is still be in your face annoying about this but not kill the process. We're still figuring out the best way for that as we can't use the exception handler for this, and we want to provide users with the full context plus a way to catch any of these unhandled errors. This possibly comes down to providing a singleton accepting a handler.

[Seldaek]

IMO you need to restore the original handler there, not wipe it.

Suggested change

	// set dummy handler and return previous handler
	$handler = set_exception_handler(static function (Throwable $throwable) {
	throw $throwable;
	});
	// use dummy handler when no original handler is available
	if ($handler === null) {
	$handler = set_exception_handler(null);
	}
	set_exception_handler(null);
	// set dummy handler and return previous handler
	$handler = set_exception_handler(static function (Throwable $throwable) {
	throw $throwable;
	});
	// use dummy handler when no original handler is available
	if ($handler === null) {
	$handler = set_exception_handler(null);
	} else {
	// restore original handler
	set_exception_handler($handler);
	}