In #20808, I adopt another approach, because catching \Error and \Exception indistinctly changes the behavior when using the application with the framework and the Debug component for instance.

I.e, with your proposal, you'll get:

[Symfony\Component\Debug\Exception\FatalThrowableError]
Call to undefined method Symfony\Component\Console\Input\ArgvInput::Option()

instead of the current:

[Symfony\Component\Debug\Exception\UndefinedMethodException]
Attempted to call an undefined method named "Option" of class "Symfony\Component\Console\Input\ArgvInput".
Did you mean to call e.g. "getOption", "getOptions", "getParameterOption", "hasOption", "hasParameterOption" or "setOption"?

See #20808 (comment) and #19813 (comment)

Note that you only get a 0 exit code when a command throws an \Error using the framework (due to the Debug component and DebugHandlersListener).
Using the component standalone, you'll get a non 0 exit code (1 or 255, see below).

I just realized there is an inconsistency in 899fa79 because, using the component standalone:

• when no event dispatcher is injected, a FatalThrowableError is thrown (1 exit code)
• when an event dispatcher is injected, the original \Error is thrown (255 exit code)

It should always throw the original \Throwable instead, for BC reasons (as expressed in #19813 (comment))

In #20797 I try to fix the issue with commands throwing \Errors in the framework by re-throwing the \Error at the end of the handler which triggers the native exception handler and exit the script with 255.

WDYT?

I was guided by the #20736, to have a simple fix for the problem. Rethrow the original exception in case of \Exception, wrap it in FatalThrowableError otherwise.

In any case, which ever solution is chosen, it should go to the 2.7 branch. PHP 7 is being deployed at a fast pace, anybody using symfony and relying on the command exit code will be in for a nasty surprise.

In any case, which ever solution is chosen, it should go to the 2.7 branch. PHP 7 is being deployed at a fast pace, anybody using symfony and relying on the command exit code will be in for a nasty surprise.

#20797 targets 2.7 and solves this issue.

Can we close this one?

The issue of 0 exit code for throwable exceptions when console is used within the symfony framework on php 7 still exists (due to the DebugHandlersListener).

The fix for this can be either in the Console/Application::run (this PR), or directly in the DebugHandlersListener (PR #20797).

We've been using this fork in production for 3 months, to avoid problems with cli queue workers.

The wrong exit code has been fixed and \Throwables are handled by the application (well, there is a BC break but this will not help), this should be closed.