Hi Daniel,
NumberFormatException already extends RuntimeException.
Class NumberFormatException
java.lang.Object
extended by java.lang.Throwable
extended by java.lang.Exception
extended by java.lang.RuntimeException
extended by java.lang.IllegalArgumentException
extended byjava.lang.NumberFormatException
Therefore it, like RuntimeException, does not need to be caught,
they are "unchecked" exceptions.
If you intend to make sure that the calling code must catch the
exception then I would suggest creating your own exception that extends
java.lang.Exception, e.g. RangeSetArgumentException.
If you don't want to force the calling code to catch the exception I would
either create my own exception that extends java.lang.IllegalArgumentException,
or just remove the try/catch block altogether. I'm certain that you
will not have to add a throws clause to the ctor. I guess you could rethrow a
new NumberFormatException with a different message.
My preference is to force the calling code to catch any wayward exceptions, so
I would suggest creating something like a RangeSetArgumentException and throwing
it in the catch clause, and adding it to the throws declaration of the ctor.
Regards,
Randy
On Tue, 2008-06-10 at 16:21 -0300, Daniel Felix Ferber wrote:
Hi,
The org.eclipse.ptp.core.util.RangeSet constructor with string parameter
contains two empty catch blocks. This was preventing me to identify an
bug where the RangeSet was being instantiated with an invalid number as
a machine ID.
Is there a special reason to swallow NumberFormatExceptions? If not, I
wouldn't it make sense to log the error or to propagate/rethrow the
exception as a RuntimeException?
Here is the code:
public RangeSet(String str) {
if (str != null) {
String[] ranges = str.split(",");
for (String range : ranges) {
String[] vals = range.split("-");
if (vals.length == 1) {
try {
add(Integer.parseInt(vals[0]));
} catch (NumberFormatException e) {
}
} else {
try {
add(Integer.parseInt(vals[0]),
Integer.parseInt(vals[1]));
} catch (NumberFormatException e) {
}
}
}
}
}
Best regards,
Daniel Felix Ferber
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev