Need of exception handler in calling function, isn't it weird???

[parkarumesh]

Hi,

I have written a function as follows

public String fetchName(String query) throws Exception
{

stmt = con.createStatement();
ResultSet rs = stmt.executeQuery(query);
rs.next();
return (rs.getString(1));
}

I've handled the for exceptions here using "throws Exception". Inspite
of that when i call it from other function and in that funtion no
exception need to be handled, compiler gives errror.

Following is the calling funtion

public String checksubAction(String action)
{
String retValue=" ";
String query="";

query = "select Title from dbo.Folder where Folder_Id="+folderId;
retValue = dataBaseObj.fetchName(query);

}

but when i write it in try-catch block, no errror is given.

Why is it that inspite of handling exception(s) in the called function,
we need to handle them in calling functions.

Thanks

 

[Ingo R. Homann]

Hi,

what you are realizing is the expected behaviour of exceptions: In
opposite to error-codes which can easily be ignored (causing much havock
and hard-to-debug errors), the compiler tries to make it harder for you
to ignore an error and to continue as if nothing happend.

I suggest reading some tutorial on exception-handling. It is not soo
difficult.

Ciao,
Ingo

 

[Bjorn Abelli]

Hi,
Hi!

I have written a function as follows

public String fetchName(String query) throws Exception
[snipped]

I've handled the for exceptions here using
"throws Exception".

Nope, on the contrary.

"throws" is a construct which tells us that this
method *doesn't* handle Exception.

Hence, any Exceptions that occur that need to be
handled are "forwarded" to the calling method.

The calling method in turn can handle or throw
the Exception, etc...

// Bjorn A



Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

 

[parkarumesh]

so Bjorn if i write the code of called function in try-catch, i won't
have to write try catch in the calling function?

 

[Bjorn Abelli]

so Bjorn if i write the code of called function in try-catch,
i won't have to write try catch in the calling function?

Yep.

You can either...

--------------------------
public void called() throws Exception {
...
}

public void calling() {
try {
called();
}
catch (Exception ex) {
// handle it here...
}
}
--------------------------
....or...
--------------------------
public void called() {
try {
...
}
catch (Exception ex) {
// ...you can handle it here...
}
}

public void calling() {
called();
}
--------------------------

However, I suggest you follow Ingo's advice, to read up on Exception
handling, as there are more details worth to know about it.

You shouldn't make a "catch-all" handler for the supertype Exception, but
try to discriminate between the Exception types, and handle them according
to what type of Exception it actually is, e.g. SQLExceptions handled in one
way, other Exceptions in other ways...

// Bjorn A



Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

 

[Thomas Hawtin]

Devil's advocate says: nah, it's easy to ignore an error; that's what
empty catch blocks are for!

Noooo!! People will see you. Put an innocuous-looking return in a
finally block. Nobody uses -Xlint.

Tom Hawtin

 

[Monique Y. Mudama]

Hi,

what you are realizing is the expected behaviour of exceptions: In
opposite to error-codes which can easily be ignored (causing much
havock and hard-to-debug errors), the compiler tries to make it
harder for you to ignore an error and to continue as if nothing
happend.

Devil's advocate says: nah, it's easy to ignore an error; that's what
empty catch blocks are for!

 

[Andrew McDonagh]

Devil's advocate says: nah, it's easy to ignore an error; that's what
empty catch blocks are for!

For me - Checked Exceptions are a pain in the ass. I tend to wrap them
in unchecked exceptions asap.

 

[Ingo R. Homann]

Hi,

For me - Checked Exceptions are a pain in the ass.

Sometimes they are, yes. But...

I tend to wrap them
in unchecked exceptions asap.

....where (on which level) do you catch the uncecked exception, then?
This can be even more pain!

Ciao,
Ingo

 

[Andrew McDonagh]

Hi,



Sometimes they are, yes. But...


...where (on which level) do you catch the uncecked exception, then?
This can be even more pain!

Ciao,
Ingo

I'm not dishing exceptions, they are much better than error codes for
all of those good reasons we know.

However, I favour the 'write exception safe code' method, that is, dont
use or limit there use where possible. For example, we could simply
write a for loop with an incrementing int until we get an
OutofBoundException from the colloection, but we dont, we either use
iterators or loop while the index (int) is less than the collection size.

On those occasions where exceptions make sense, I make sure each layer
within the applications only expose their exceptions, not lower layer
exceptions. This means wrapping lower layer exceptions within new ones.
These new ones then add more context information to the lowlevel
exception.

Simplistic E.g.

a low level DB Exception - DBConnectionRefusedException("SQL: db not
contactable or offline - error code 1234")

Which would be wrapped by the model layer -
DatabaseConnectionFailureException("Unable to connect to Database
(MySystemDatabase)");

 

[Ingo R. Homann]

Hi,

On those occasions where exceptions make sense, I make sure each layer
within the applications only expose their exceptions, not lower layer
exceptions. This means wrapping lower layer exceptions within new ones.
These new ones then add more context information to the lowlevel
exception.

Yes, that's how it is supposed to be.

But my question is: why do you want to wrap them in a
*Runtime*Exceptions? I think that makes it more difficult to decide
where to catch it (because the layer above does not necessarily know
that this exception is thrown)!

Ciao,
Ingo