Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cause exception not printed by default execution exception handler #1048

Closed
remkop opened this issue May 15, 2020 · 8 comments
Closed

Cause exception not printed by default execution exception handler #1048

remkop opened this issue May 15, 2020 · 8 comments
Milestone

Comments

@remkop
Copy link
Owner

remkop commented May 15, 2020

When an exception occurs in the business logic, this is handled by the execution exception handler. By default, this prints the full stack trace of the exception.

Since 4.3.0, only the stack trace of the "outer" exception is printed. If that exception has any "cause" exceptions, these are incorrectly omitted.

With the work done in #484, #845 and #1008 (colors in exception handler), we no longer call exception.printStackTrace() but instead have a custom implementation that has the same effect but uses ANSI colors. This implementation incorrectly omits the stack trace for any nested "cause" exceptions (and their nested cause, if any).

A workaround is to register a custom execution exception handler as follows:

new CommandLine(new MyApp())
        .setExecutionExceptionHandler(
            (Exception ex, CommandLine commandLine, ParseResult parseResult) -> {
                        ex.printStackTrace();
                        return commandLine.getCommandSpec().exitCodeOnExecutionException();
            })
        .execute(args);
@remkop remkop added this to the 4.3.2 milestone May 15, 2020
@jerrylususu
Copy link
Contributor

Sorry for the bug introduced. Working on a permanent fix.

@jerrylususu
Copy link
Contributor

One easy fix would redirect all the output from ex.printStackTrace() to a string, as proposed in #845. However, doing so may harm the ability to split exception messages from stack traces.

@jerrylususu
Copy link
Contributor

Seems extend StringWriter to write Style.on() before and Style.off() after is one viable solution. Testing locally.

@jerrylususu
Copy link
Contributor

Mostly done...
image

jerrylususu added a commit to jerrylususu/picocli that referenced this issue May 15, 2020
This commits tries to fix remkop#1048. The bug is caused by re-implementing printStackTrace() method on our own. Here, by using the original implementation, the causes can be printed as intended. By extending StringWriter, exceptions messages and stack traces can be separated, then applied to different styles.
jerrylususu added a commit to jerrylususu/picocli that referenced this issue May 15, 2020
remkop added a commit that referenced this issue May 16, 2020
jerrylususu added a commit to jerrylususu/picocli that referenced this issue May 16, 2020
This commits tries to fix remkop#1048. The bug is caused by re-implementing printStackTrace() method on our own. Here, by using the original implementation, the causes can be printed as intended. By extending StringWriter, exceptions messages and stack traces can be separated, then applied to different styles.
jerrylususu added a commit to jerrylususu/picocli that referenced this issue May 16, 2020
@jerrylususu
Copy link
Contributor

jerrylususu commented May 16, 2020

By the way, here is a strange table about the compatibility of ANSI style.

image

@remkop remkop closed this as completed in 30ce002 May 16, 2020
remkop pushed a commit that referenced this issue May 16, 2020
remkop added a commit that referenced this issue May 16, 2020
remkop added a commit that referenced this issue May 16, 2020
@remkop
Copy link
Owner Author

remkop commented May 16, 2020

Thanks for the help!
I just released picocli 4.3.2 with this fix.

About the terminals, there is not much we can do about that in the application. The best we can do is select colors and styles that look acceptable in most consoles. (Which I think we did.) :-)

@jerrylususu
Copy link
Contributor

Sorry for the bug introduced! Hope 4.3.2 will be the last patch version of 4.3, and wish everything goes well!

@remkop
Copy link
Owner Author

remkop commented May 16, 2020

No worries!
That’s software!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants