commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: svn commit: r1030464 [1/3] - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/ main/java/org/apache/commons/math/analysis/ main/java/org/apache/commons/math/analysis/integration/ main/java/org/apache/commons/math/analysis/inte
Date Fri, 05 Nov 2010 16:44:51 GMT
> > > 
> > > I don't know if it's relevant here, but it's standard practice in
> > lots
> > > of code I've seen to document unchecked exceptions in the @throws
> > > block if your code explicitly throws it.
> > 
> > This would be the minimum, but it seems that CM tries to be better in
> > that
> > it aims at also documenting the exceptions thrown from the called
> > code.
> No. We try to explain what the user could throw or rather provide guidelines
> on what to throw.


My sentence had nothing to do with user code.
It is a compliment about CM trying to fully document its own code, including
the exceptions that could be thrown from CM methods called be other CM
methods. This is indeed invaluable help because there is no other way
(short of reading the source code) for a user to know what to expect from
one level deeper than the methods he directly calls.

> > Of course it is more work on the part of the developer and also more
> > difficult do check for consistency when reading the code (short of
> > following
> > all the calls).
> Yes, and it what I like in checked exception, [...]

It doesn't help because unchecked exceptions exist!
If only checked exception existed, then yes, self-consistency could be
achieved easily.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message