---

This section details on the original issue you should resolve

<issue_title>Runner.php is catching overly specific exception?</issue_title>
<issue_description>## Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

It seems like Runner.php catches only a very specific exception type.

When a command is executed, the only exceptions that are caught and transformed to STDERR outputs are exceptions of type WP_CLI\Iterators\Exception.

Other exceptions bumble up to the global WordPress fatal error handler and will go through wp_die and display the default fatal error message:

There has been a critical error on this website.Learn more about troubleshooting WordPress. There has been a critical error on this website.

In PHPStorm I could not find any places where WP_CLI\Iterators\Exception is thrown beside in Query.php.

Is this behaviour intentional? I would expect that wp-cli transforms uncaught exceptions to STDERR output at some point.

Describe how other contributors can replicate this bug

WP_CLI::add_command('foo', function () {
    throw new \Exception('foo message');
});

wp foo

Describe what you expect as the correct outcome

I would expect to see the following terminal output:

Error: foo message

And a log message written to the default configuration using error_log

Let us know what environment you are running this on

Shell:  /bin/zsh
PHP binary:     /usr/local/Cellar/php@7.4/7.4.28_1/bin/php
PHP version:    7.4.28
php.ini used:   /usr/local/etc/php/7.4/php.ini
MySQL binary:   /usr/local/bin/mysql
MySQL version:  mysql  Ver 8.0.28 for macos11.6 on x86_64 (Homebrew)
SQL modes:      ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
WP-CLI root dir:        phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      phar://wp-cli.phar/vendor
WP_CLI phar path:       /Users/calvinalkan
WP-CLI packages dir:    /Users/calvinalkan/.wp-cli/packages/
WP-CLI global config:   
WP-CLI project config:  
WP-CLI version: 2.6.0

</issue_description>

Comments on the Issue (you are @copilot in this section)

@danielbachhuber @calvinalkan @johnbillion Would either of you like to put together a pull request with your suggested changes?

Catching exceptions thrown by commands seems helpful to me, although WP-CLI remains the last mechanism to catch the exception.

WP-CLI has a custom wp_die_handler we may be able to improve in some way:

wp-cli/php/utils-wp.php

Lines 86 to 104 in 0b22dee

	function replace_wp_die_handler() {
	\remove_filter( 'wp_die_handler', '_default_wp_die_handler' );
	\add_filter(
	'wp_die_handler',
	function() {
	return __NAMESPACE__ . '\\wp_die_handler';
	}
	);
	}
	function wp_die_handler( $message ) {
	if ( $message instanceof \WP_Error ) {
	$message = $message->get_error_message();
	}
	$message = wp_clean_error_message( $message );
	WP_CLI::error( $message );
	}