two java grammar questions

C

Chenxi

Hi,

I have two pieces of sample code which are listed below. I dont understand
two points.

1. why so many exceptions (IOException, JMSException, etc), normally we just
catch Exception. Is there any advantage?

2. what is the difference between finally and no finally? see the code.
connection.close() will be invoked. why use finally?

Thank you.

Chenxi

=====
try{
// initialising code
connection = ...
...
}catch(IOException e){
...
}catch(JMSException e){
...
}finally{
if (connection!=null)
connection.close();
}

=======
try{
// initialising code
connection = ...
...
}catch(Exception e){
...
}

if (connection!=null)
connection.close();
 
I

Ingo R. Homann

Hi,
Hi,

I have two pieces of sample code which are listed below. I dont understand
two points.

1. why so many exceptions (IOException, JMSException, etc), normally we just
catch Exception. Is there any advantage?

Inside your method, its an advantage to catch the exceptions
specifically, if you want to do different things when different
Exceptions are thrown. Otherwise, you can catch all exceptions.

When *declaring* exceptions in the method-head, its always useful to
decalre them specifically, so that the caller of your method can see
specifically which exceptions are thrown.
2. what is the difference between finally and no finally? see the code.
connection.close() will be invoked. why use finally?

Consider the following:
try{
// initialising code
connection = ...
...
}catch(IOException e){
...
}catch(JMSException e){
DoSomwthingThatMayThrowAnotherException();

}finally{
if (connection!=null)
connection.close();
}

Doing it without finally, the connection will not be closed.

Ciao,
Ingo
 
S

Sudar

Hi Chenxi,

1) It is always good to catch specific exceptions instead of using the
general Exception. We can take specific recovery action based on the
exception which is being caught. For instance in your example, the
program may continue by just alerting the user in case of the
IOEception is throw, but may have to stop all processing incase of
JMSException. So it is possible only when you catch specific
exceptions.

2) It is again advisable to use the finally block for closing the
connection instead of just checking whether the connection is null or
not. Because the finally block will execute even in case the processing
is stopped due to an exception. But if we check whether the connection
is null and the try to close it then we have to specify that if block
in all the catch block so that the connection is closed even if some
exception occurs.

One of the main advantages of using java is its structured way to
handle exceptions.
Hope this clears your doubt.
 
J

jan V

1. why so many exceptions (IOException, JMSException, etc), normally we
just
catch Exception. Is there any advantage?

Repeat after me: "I shall NEVER catch Exception", "I shall NEVER catch
Exception", "I shall NEVER catch Exception", ...

Why? Because that way you also catch NullPointerException,
IllegalArgumentException, and all the other exception types which indicate
BUGS in your code, not just exceptional program conditions.

That's a good enough reason no? ;-)
 
A

Andrew Thompson

Repeat after me: "I shall NEVER catch Exception", "I shall NEVER catch
Exception", "I shall NEVER catch Exception", ...

So ..catching 'Throwable' is fine then? [ ;-) ]
 
S

Stefan Schulz

Repeat after me: "I shall NEVER catch Exception", "I shall NEVER catch
Exception", "I shall NEVER catch Exception", ...

Disagree here. I occasionally write code like this

catch (Exception e){
if (e instanceof RuntimeException)
throw (RuntimeException) e;
else {
// report the exception, do something about it
}
}

Or even

catch (Exception e){
throw new FooException(e);
}
Why? Because that way you also catch NullPointerException,
IllegalArgumentException, and all the other exception types which indicate
BUGS in your code, not just exceptional program conditions.

Its not necessarily your code, for example imagine you wrote some
Threadpooling code because the java 1.5 Executors break a bit too easily
(try submitting 15000 tasks to one of these). Such a thread should even
survive one of the "bug" RuntimeExceptions, and return to the pools, after
making sure to report it to the appropriate places.
 
T

Thomas Hawtin

Stefan said:
Disagree here. I occasionally write code like this

catch (Exception e){
if (e instanceof RuntimeException)
throw (RuntimeException) e;
else {
// report the exception, do something about it
}
}

That's a bad way of coding a bad design. Sometimes you want to catch
absolutely everything even if it has evaded exception checking, but that
would be catch Throwable. Even if you were to catch Exception except
RuntimeException, better to write it as

// Do not do this.
} catch (RuntimeException exc) {
throw exc;
} catch (Exception exc) {
...
Or even

catch (Exception e){
throw new FooException(e);
}
Its not necessarily your code, for example imagine you wrote some
Threadpooling code because the java 1.5 Executors break a bit too easily
(try submitting 15000 tasks to one of these). Such a thread should even
survive one of the "bug" RuntimeExceptions, and return to the pools, after
making sure to report it to the appropriate places.

I would have thought you would be more likely to get an Error is such
circumstances. What do you do if it fails?

But why not be more specific. There's never any point in being exactly
as specific as Exception.

Tom Hawtin
 
J

jan V

Repeat after me: "I shall NEVER catch Exception", "I shall NEVER catch
Exception", "I shall NEVER catch Exception", ...

So ..catching 'Throwable' is fine then? [ ;-) ]

Of course, there *are* situations where you need to take the extreme step of
catching Throwable... but these situations typically have to do with
fault-tolerance/robustness of an _entire_ system, and as such will only be
needed in one location (singleton, etc..).

For 99.99% of your catch clauses, my original warning still stands. IMO, you
really want NullPointerException and its friends to slam into your face hard
and painfully, so that you feel the negative feedback... in the hope of
writing fewer bugs next time. I don't believe in catching Exception like so
many people do, and just logging it (or worse), etc.. because that's just
one step away from using duct tape on your system's flaws.

What I often do when hitting a NullPointerException is to quickly go to the
source of the method that threw it, and add an extra

if ( x == null) {
throw new IllegalArgumentException("..... can't be null.");
}

[I'd be using asserts for this if I used 1.5 Java language features, but I
don't yet]

... and document the javadocs for the method accordingly. That way, I make
quite clear that the caller is at fault, not the callee.
 
J

John Currier

Disagree here. I occasionally write code like this
catch (Exception e){
if (e instanceof RuntimeException)
throw (RuntimeException) e;
else {
// report the exception, do something about it
}
}

Wouldn't it be cleaner/clearer to do this instead?

} catch (RuntimeException runtime) {
throw runtime;
} catch (Exception exc) {
// do something significant here
}

Of course I personally wouldn't catch Exception without significant
cause.

John
http://schemaspy.sourceforge.net
 
R

Raymond DeCampo

jan said:
Repeat after me: "I shall NEVER catch Exception", "I shall NEVER catch
Exception", "I shall NEVER catch Exception", ...

Why? Because that way you also catch NullPointerException,
IllegalArgumentException, and all the other exception types which indicate
BUGS in your code, not just exceptional program conditions.

That's a good enough reason no? ;-)

I disagree here. Suppose you are writing a program for public
consumption. It is unacceptable to the end user for your program to
simply stop because an uncaught exception terminated the thread. It is
better to catch the exception and advise the user of the proper course
of action (which may be contacting the authors to advise them of their
programming flaw).

Ray
 
J

jan V

That's a good enough reason no? ;-)
I disagree here. Suppose you are writing a program for public
consumption.

I agree with you. See my answer to Andrew in this thread.

XML is also the hammer turning every problem into a nail.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top