-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I only have 2 real problems here:
1. MojoExecutionException, which is meant to be a wrapper for some unknown exception. This could be anything, and we REALLY cannot guarantee that it's root cause is expressed in the top-level exception's message, unless we're digging to root cause inside that exception (not easy, given the restrictions on where you can call super(..)). 2. Unknown exceptions, which haven't been vetted as thoroughly as all that. This could be from API changes to upstream components like SCM, wagon, or plexus; or, it could be from new exceptions added to the maven ~ API without as thorough an examination as you apparently did. In the first case, we simply need to push as far down as we can into the exception stack and pull out the bottom exception. It would also probably be worth pulling out the next-level (1 down from the top) message and displaying that, just in case someone threw in useful information at that level. Printing the error message thrown by the mojo developer seems like we're putting too much faith in plugin developers to produce accurate, thoughtful error messages. I'd say, pull first-level and root-level error messages/types for these. In the second case, we have an API expansion problem that hasn't had the attention given to our current API. I agree that this isn't an ideal situation, but if error diagnosis were in an ideal state, this diagnoser could output "HELP" and it wouldn't matter; it'd never be seen. This is the last line of defense for interpreting an unknown error...it should print out the most useful information in any initial debugging effort: a. top-level exception class b. top-level exception message c. root-level exception class d. root-level exception message Obviously, either of these cases will mean that determinedly dense developers can cut the exception chain and throw a completely new exception, swallowing the original exception and stack trace. However, in these cases, we're left guessing at what the real problem is. Users will be, too, and -X will be the first step in debugging. Why not simply add a new layer, that attempts to help? If it doesn't help, we're right back to -X, with no harm done. Based on your reply, and my reply to that above, I'm putting these changes back into those two diagnoser classes. If this is still a problem, we can discuss it more in the morning (.au time). - -j Brett Porter wrote: | I'd planned to summarise what I did here tomorrow as its late... | | I very carefully audited every exception in the codebase and ensured | that the message of each exception always captured any appropriate | message from the cause. There are no more "shoulder shrugs". | | The root simply duplicated all of these (which looked silly), and is | easily obtained by the trace as you mention (with -e, not -X). | | If you want to restore and: | a) you guarantee it doesn't duplicate the original message (which it did | even before I did the above audit) | b) that it actually gets the root cause (f.e., the root cause of | ArtifactResolutionException was coming back as "Could not get artifact | from any repositories" instead of the error of ResourceNotFoundException). | | I'd appreciate testing on the error reporting. I think what we have now | is pretty good - can you find a specific example where it is not the case? | | - Brett | | John Casey wrote: | | |>Why on earth would you remove the root causes from all of these |>diagnosers?? Particularly the PuntDiagnoser? |> |>Often, the root cause is the only thing that makes any sense...the rest |>is just heaps of string-literal shoulder-shrugs that are too digested to |>be of any help. If we can't get at the root cause, especially when its |>hiding behind something like MojoExecutionException, or some otherwise |>undiagnosed exception (PuntDiagnoser), many problems will be a complete |>mystery. Not to mention the MNG issues this will reopen... |> | | | --------------------------------------------------------------------- | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDTrVcK3h2CZwO/4URAqM+AKCdmaXzaeo//VvCZ8rnCW9ysVrHzQCdFH/P kpZZLfQWaF9Bma1Ccc8Pv7E= =pmwK -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
