two java grammar questions

Thread view:

Chenxi - 22 Jul 2005 11:18 GMT

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();

Reply to this Message

Ingo R. Homann - 22 Jul 2005 11:50 GMT

Hi,

> Hi,
>
[quoted text clipped - 3 lines]
> 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
[quoted text clipped - 3 lines]
> ...
> }catch(JMSException e){

DoSomwthingThatMayThrowAnotherException();

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

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

Ciao,
Ingo

Reply to this Message

Sudar - 22 Jul 2005 11:53 GMT

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.

--
Sudar MCP MCDBA MCAD
www.SudarMuthu.blogspot.com (My Certification Experiences)

Reply to this Message

jan V - 22 Jul 2005 19:22 GMT

> 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? ;-)

Reply to this Message

Andrew Thompson - 22 Jul 2005 19:38 GMT

>> 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", ...

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

Signature

Andrew Thompson
physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
Beats A Hard Kick In The Face

Reply to this Message

jan V - 22 Jul 2005 22:21 GMT

> > 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.

Reply to this Message

Stefan Schulz - 22 Jul 2005 20:52 GMT

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.

Signature

You can't run away forever,
But there's nothing wrong with getting a good head start.
--- Jim Steinman, "Rock and Roll Dreams Come Through"

Reply to this Message

Thomas Hawtin - 22 Jul 2005 21:25 GMT

>>Repeat after me: "I shall NEVER catch Exception", "I shall NEVER catch
>>Exception", "I shall NEVER catch Exception", ...
[quoted text clipped - 8 lines]
> }
> }

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
>
[quoted text clipped - 6 lines]
> 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

Signature

Unemployed English Java programmer

Reply to this Message

John Currier - 23 Jul 2005 01:44 GMT

> Disagree here. I occasionally write code like this
>
[quoted text clipped - 5 lines]
> }
> }

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

Reply to this Message

Raymond DeCampo - 23 Jul 2005 02:28 GMT

>>1. why so many exceptions (IOException, JMSException, etc), normally we
>
[quoted text clipped - 10 lines]
>
> 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

Signature

XML is the programmer's duct tape.

Reply to this Message

jan V - 23 Jul 2005 09:13 GMT

> > 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 the programmer's duct tape.

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

Reply to this Message

two java grammar questions

Free Magazines