error handling and reporting strategy

[John Casey <jd...@commonjava.org>]

I wanted to open the discussion on how best to handle errors in maven2. 
More and more often, I've been seeing that our own development efforts 
have been hampered by missing, insufficient, or incorrect debug 
information. Also, if you look through the code, more often than not 
methods have a "throws Exception" clause tacked onto the end, which 
means that we're not even attempting to diagnose the severity, 
recoverability, or whatever of these errors.

I'd like to come up with some sort of strategy for interpreting these 
errors and formatting some sort of display for output, and then allow a 
development mode and a normal mode, which will be quieter - much like m1 
does.

 From my perspective, this problem screams for an aspect-oriented 
approach, something that would intercept any errors, put them through a 
ResourceBundle-based formatter, and report them to the user in a common 
way. I don't think that wrapping errors is the answer, since if all we 
do is pass them to the top and then call ex.printStackTrace() this is 
really no better than the current state.

I understand that AOP is still a very new technology, and that using it 
would probably raise the bar for maven2 core development, so I'm not 
going to push this idea too hard...only make it known that this is my 
preferred approach. Also, through proper implementation (using 
advice/pointcuts to hand errors off to other "normal" java 
infrastructure), the AOP could be kept to a minimum and easily 
maintained by a small group of developers.

Jason: you may ask about overhead, but the aspectjrt.jar for 1.2 is only 
35k...

Please, what does everyone think? This feels like an infrastructural 
need, to allow it to hook into IDE's etc. through the use of some sort 
of monitor interface.

Thanks,
John

Re: error handling and reporting strategy

[Trygve Laugstøl <tr...@inamo.no>]

On Sun, Aug 15, 2004 at 02:36:16AM -0400, John Casey wrote:
> I wanted to open the discussion on how best to handle errors in maven2. 
> More and more often, I've been seeing that our own development efforts 
> have been hampered by missing, insufficient, or incorrect debug 
> information. Also, if you look through the code, more often than not 
> methods have a "throws Exception" clause tacked onto the end, which 
> means that we're not even attempting to diagnose the severity, 
> recoverability, or whatever of these errors.

"throws Exception" is bad and shouldn't exist. One tool for finding bad
stuff like this and other things like empty catch statements which has
occurred that comes to mind is checkstyle.

I suggest that someone should try to make a plugin for checkstyle and try
to run it on our own code. I don't know if findbugs, PMD or any of the
others is more suitable but some automated help is needed.

> 
> I'd like to come up with some sort of strategy for interpreting these 
> errors and formatting some sort of display for output, and then allow a 
> development mode and a normal mode, which will be quieter - much like m1 
> does.

A mechanism for taking a build which a error as a result and sending the
entire log and stacktraces has been discussed and I think it should be
implemented. This implies that all log statements must be captured even if
they are only stored in memory and not written to the console.

> 
> From my perspective, this problem screams for an aspect-oriented 
> approach, something that would intercept any errors, put them through a 
> ResourceBundle-based formatter, and report them to the user in a common 
> way. I don't think that wrapping errors is the answer, since if all we 
> do is pass them to the top and then call ex.printStackTrace() this is 
> really no better than the current state.
> 
> I understand that AOP is still a very new technology, and that using it 
> would probably raise the bar for maven2 core development, so I'm not 
> going to push this idea too hard...only make it known that this is my 
> preferred approach. Also, through proper implementation (using 
> advice/pointcuts to hand errors off to other "normal" java 
> infrastructure), the AOP could be kept to a minimum and easily 
> maintained by a small group of developers.

As of right now m2 doesn't have any AOP support so that would be a first
step to getting it into maven 2. Personally I don't know if AOP the golden
solution, but I really haven't used AOP :)

There is a plexus-compiler implementation that used the AJ compiler which
should be pretty easy to get working. 

Anyway, I'm signing off for now. I'm going back to the land of vikings and
hope I don't get to do any computer related activities for a while.

--
Trygve

> 
> Jason: you may ask about overhead, but the aspectjrt.jar for 1.2 is only 
> 35k...
> 
> Please, what does everyone think? This feels like an infrastructural 
> need, to allow it to hook into IDE's etc. through the use of some sort 
> of monitor interface.
> 
> Thanks,
> John

Re: error handling and reporting strategy

[Jason van Zyl <jv...@maven.org>]

On Sun, 2004-08-15 at 02:36, John Casey wrote:
> I wanted to open the discussion on how best to handle errors in maven2. 
> More and more often, I've been seeing that our own development efforts 
> have been hampered by missing, insufficient, or incorrect debug 
> information. Also, if you look through the code, more often than not 
> methods have a "throws Exception" clause tacked onto the end, which 
> means that we're not even attempting to diagnose the severity, 
> recoverability, or whatever of these errors.

As far as "throws Exception" goes there are ~ 6 places in maven-artifact
that need dealing with and ~25 in maven-core that need dealing with. The
code is relatively small so I don't think it would be difficult to
funnel all exception handling into one location in the Maven component.

> I'd like to come up with some sort of strategy for interpreting these 
> errors and formatting some sort of display for output, and then allow a 
> development mode and a normal mode, which will be quieter - much like m1 
> does.

+1

It would be fabulous to have the error messages i18n-ize, have the
message give a standard pointer to a FAQ, wiki or some other resource
and provide an easy way for the user to push a debug trace to us for
analysis.

>  From my perspective, this problem screams for an aspect-oriented 
> approach, something that would intercept any errors, put them through a 
> ResourceBundle-based formatter, and report them to the user in a common 
> way. I don't think that wrapping errors is the answer, since if all we 
> do is pass them to the top and then call ex.printStackTrace() this is 
> really no better than the current state.

I have nothing against trying that and in general I've always want to
have a standard set of aspects to use with Plexus so this methodology
could easy be applied as maven is a plexus-based system. Though with
maven2 there are not many places without specialized exceptions and they
should all be pushed up to the Maven component for handling. We have
control over the lion's share of the code so we're not in a situation
where we need to weave exception handling code into third party JARs to
assist with poor error handling. That said I really do like AspectJ and
wouldn't at all mind its use in m2.

> I understand that AOP is still a very new technology, and that using it 
> would probably raise the bar for maven2 core development, so I'm not 
> going to push this idea too hard...

I have no problem with using AspectJ and I don't think it's beyond any
of the core m2 developers. There are also lots of books now, tons of
doco.

> only make it known that this is my 
> preferred approach. Also, through proper implementation (using 
> advice/pointcuts to hand errors off to other "normal" java 
> infrastructure), the AOP could be kept to a minimum and easily 
> maintained by a small group of developers.
> 
> Jason: you may ask about overhead, but the aspectjrt.jar for 1.2 is only 
> 35k...

Yah, I have no concern there. I tried it in the first version of m2 and
I removed it's use to try and make things more simple for people trying
to poke around for the first time, but I'm not concerned with that
anymore.

> Please, what does everyone think? This feels like an infrastructural 
> need, to allow it to hook into IDE's etc. through the use of some sort 
> of monitor interface.

I think a first attempt should be made to try and make specialized
exception where appropropriate, enumerate the possible error conditions
and make sure they are all surfacing to the Maven component. For the
vast majority of scenerios, if not all, I believe we have control over
the code in question so Exceptions should be surfacing in the Maven
component.

We probably need to settle on a base exception class as I've overused
the chained exceptions available in 1.4 which obviously isn't going to
work for 1.3 users. We can also get one of the reports running for the
code like PMD, Checkstyle or findbugs to help us eliminate the remaining
vague sections of execption handling. I would like to do that before
attempting any AOP solution.

> Thanks,
> John

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau