Jon Sequeira

When you invoke a command directly like this, it gets wrapped with the default middlewares including `UseExceptionHandler`. This is intended to handle exceptions very generally but if you want to...

@AndrewSav Typically if you're wiring up the `CommandLineBuilder` our assumption is you'll call `Invoke` on the parser returned by its `Build` method rather than using the `Command.Invoke` extension method.

As a middleware, `UseExceptionHandler` applies to all commands, so it satisfies DRY. You can customize it by passing your own delegate if you want to change the default behaviors, which...

Not enabling it by default means the default behavior on an unhandled exception is a process crash, a stack trace, and possible triggering of the just-in-time debugger. It's also not...

It's often said that the difference between a library and a framework is that you call a library whereas a framework calls you. By that definition anyway, some parts of...

Any suggestions on an API for opting out of this? A related problem that needs to be solved is how extension methods like `Command.Invoke` should behave, given that under the...

The `Symbol` types don't know anything about the details of invocation (other than having a pointer to a handler). We wouldn't want to duplicate invocation functionality into `Command`. The invocation,...

> It's odd that you wouldn't be able to add middleware to a root command using an API exposed on the root command instance. There's a single middleware pipeline per...

> Command owns the state because CommandLineBuilder sets Command.ImplicitParser. This is an implementation detail which is subject to change. This is effectively just a cache. > There's only one root...

```csharp return await rootCommand .Configure(config => config.UseDefaultExceptionHandler = false) // Returns some new type or a Parser instance maybe .InvokeAsync(args); ``` I think in isolation this API is pretty intuitive....