«

I read this in a Java book about Declaring a method that throws
exceptions: "The Declaration itself doesn't do anything to actually
throw that exception should it occur; you have to do that yourself in
the body of the method".

In line with the above, I fail to understand the following piece of
code. It declares that it throws 'Exception' but then, does not
actually 'throw' it. I think I am missing some fundamental concept.

public static String format(String strData, int finalLen) throws
Exception
{
String finalStr;
if (finalLen <= strData.length())
{
finalStr = strData.substring(0, finalLen);
}
else
{
finalStr = strData;
for (int i = strData.length(); i < finalLen; i++)
{
finalStr = finalStr + " ";
}
}
return (finalStr);
} // format(String, int)

TIA
Raquel.

Raquel wrote:
> In line with the above, I fail to understand the following piece of
> code. It declares that it throws 'Exception' but then, does not
> actually 'throw' it. I think I am missing some fundamental concept.

a) Please post beginner's questions to comp.lang.java.help

b) format() calls a number of other methods (substring(), length())
Investigate if any of these might throw an exception. If they do, and
since they are not catched in format(), the exceptions will propagate
upwards to the caller of format().

c) It might be that this is a method intended to be overridden in
sub-classes and that the author wants to allow sub-classes to throw the
exception. Therefore he/she declared it in the superclass but didn't
throw one in the implementation.

d) It might be an error.

e) Throwing generic exceptions like "Exception" is not a good idea in
most cases. Instead the exception should be as specific as possible.
This makes it easier for the caller of the method to anticipate the
possible failure modes and provide handling code.

/Thomas

Raquel <> scribbled the following:
> I read this in a Java book about Declaring a method that throws
> exceptions: "The Declaration itself doesn't do anything to actually
> throw that exception should it occur; you have to do that yourself in
> the body of the method".

> In line with the above, I fail to understand the following piece of
> code. It declares that it throws 'Exception' but then, does not
> actually 'throw' it. I think I am missing some fundamental concept.

It calls a lot of other methods, any of which can throw an exception.
If such a thing happens, then this method also throws the same
exception.

> public static String format(String strData, int finalLen) throws
> Exception
> {
> String finalStr;
> if (finalLen <= strData.length())
> {
> finalStr = strData.substring(0, finalLen);
> }
> else
> {
> finalStr = strData;
> for (int i = strData.length(); i < finalLen; i++)
> {
> finalStr = finalStr + " ";
> }
> }
> return (finalStr);
> } // format(String, int)

--
/-- Joona Palaste () ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Life without ostriches is like coffee with milk."
- Mika P. Nieminen

Raquel wrote:

> I read this in a Java book about Declaring a method that throws
> exceptions: "The Declaration itself doesn't do anything to actually
> throw that exception should it occur; you have to do that yourself in
> the body of the method".
>
> In line with the above, I fail to understand the following piece of
> code. It declares that it throws 'Exception' but then, does not
> actually 'throw' it. I think I am missing some fundamental concept.

In a method, an exception can't just happen when it's
explicitly thrown, it can also be thrown in a different
method called inside your method. This way, exceptions
propagate upwards in the method call stack until they are
caught at some point.

But the code you cited is very badly written, apparently by
a lazy or incompetent programmer. Declaring a method to throw
java.lang.Exception is pointless; a method should only declare
specific exceptions and there should be API documentation that
describes under what circumstances they occur, so that callers
know what to expect and can handle it.

Furthermore, the only exception that can actually occur in that
method is the NullPointerException, so it should either

- deal with null arguments in some sensible way
- declare NullPointerException
- declare nothing. NPE is a subclass of RuntimeException and those
need not be declared at all because, like NPE, they can occur
just about anywhere.

Thank you Joona, Michael and Thomas for very informative replies. This
makes things clear.

Regards,
Raquel.