Closed 89netraM closed 4 years ago
Thanks for the PR!
I think we should drop UseShortErrors
, I highly doubt anyone is going to configure this as in pretty much every case you want as detailed error messages as possible.
Great! I'll get straight to your comments.
Thanks! One thing to consider: on the off chance that parsing fails, can we guarantee that the unformatted error message will be shown anyway?
Good point. No, probably not.
The exception type and message isn't parsed and can't fail so there's no need to check them.
But as for the stack trace, unless the format of the stack trace is change I'm pretty sure it can't fail, but that's no guarantee. I can add a check that if any parsing fails the original stack trace will be printed instead.
What do you think?
Maybe we should try to parse the full stacktrace in one go instead of going by each line separately. So that way if any of the matches fail, we can just fallback to unformatted version easily.
Yes, exactly!
I'll get right on it.
Looks good! Thanks!
This PR adds functionality that parse, formats, and highlights any exception that is thrown.
Error messages can also be shortened with the use of
UseShortErrors
when building theCliApplication
. This option is stored in theApplicationConfiguration
.The printout of two error messages. First is without the
UseShortErrors
option, and the second is with. Otherwise they're the same.I've added a test that checks that printed error messages do not contain any fully qualified names when the
UseShortErrors
option is activated. And I also change the existing test of error printing to check that the fully qualified names are there.Should close #78