Wouldn't it be easier to add the current ITypeResolver to the existing ErrorHandling?

@nils-a Apologies, I'm having a bit of difficulty understanding what you're suggesting. Could you please explain it?

OT: Force pushed because i wanted a cleaner diff. The CommandExecutor appearantly is in mixed mode (LF & CRLF). vscode messes it up.

@JKamsker the currently existing way to handle exceptions is:

var app = new CommandApp<DefaultCommand>();
app.Configure(config =>
{
    config.SetExceptionHandler(err =>
    {
        AnsiConsole.WriteException(err);
        // or whatever....
    });
});

I don't quite like the idea of adding another, different way to do exception handling.

So: If you need the ITypeResolver while handling exceptions, my proposal was to add the ITypeResolver to the exception handler like this:

var app = new CommandApp<DefaultCommand>();
app.Configure(config =>
{
    config.SetExceptionHandler((err, resolver) =>
    {
        var console = (IAnsiConsole)resolver.Resolve(typeof(IAnsiConsole));
        console.WriteException(err);
        // or whatever....
    });
});

@nils-a Oh yea, that seems like a neat idea! Why haven't i thought about this? 😅
Would adding an overload like SetExceptionHandler<TCommand> be acceptable?

Would adding an overload like SetExceptionHandler be acceptable?

Hm. Do you really need different handlers for different Commands? I have the feeling this would make things rather complicated.
Wouldn't it be easier, in that case, to create your own ICommand that is capable of handling exceptions?

Superseded by #1411.