aspose file tools*
The moose likes Beginning Java and the fly likes Exception Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Exception" Watch "Exception" New topic
Author

Exception

Joseph Sweet
Ranch Hand

Joined: Jan 29, 2005
Posts: 327
Suppose that in a certain method, i catch an exception, and from within that catch clause, I throw someKindOfException. Why don't I need then to define the method as "throws someKindOfException" ???

Thank you in advance.
[ March 26, 2007: Message edited by: Joseph Sweet ]

We must know, we will know. -- David Hilbert
Keith Lynn
Ranch Hand

Joined: Feb 07, 2005
Posts: 2367
Can you be specific about which exceptions you're throwing?
Joseph Sweet
Ranch Hand

Joined: Jan 29, 2005
Posts: 327
I throw an EJBException:

Keith Lynn
Ranch Hand

Joined: Feb 07, 2005
Posts: 2367
I don't use J2EE much, but if I'm looking at the right documentation, EJBException is a subclass of RuntimeException, so it is unchecked.
Joseph Sweet
Ranch Hand

Joined: Jan 29, 2005
Posts: 327
Right...
But why throwing an unchecked exception?
Keith Lynn
Ranch Hand

Joined: Feb 07, 2005
Posts: 2367
Originally posted by Joseph Sweet:
Right...
But why throwing an unchecked exception?


I'm not sure what you're asking.
Joseph Sweet
Ranch Hand

Joined: Jan 29, 2005
Posts: 327
Aren't developers supposed to throw only checked exceptions?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 13884
    
  10

Originally posted by Joseph Sweet:
Aren't developers supposed to throw only checked exceptions?

No, where did you read that and what was the reason given?


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36598
    
  16
Jesper Young, I think Jonathan Sweet read about not throwing unchecked Exceptions
here, in the Java Tutorial.
[ March 27, 2007: Message edited by: Campbell Ritchie ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
That's a fairly controversial subject. Java's designers tried a bold experiment with checked exceptions. Few other languages - none that I've used, I think - have them. A number of respectable people think checked exceptions were not such a great idea, and suggest using unchecked as much as you can. It takes a different discipline to work that way, and maybe a design that's built around it from the start. I had great success with unchecked exceptions in one system, but I wouldn't try to change the way the massive systems at work use checked exceptions.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joseph Sweet
Ranch Hand

Joined: Jan 29, 2005
Posts: 327
When code throws a RuntimeException, does the JVM look for a catch clause that might catch it?

If it does, does it execute the finally clause before looking for a catch clause upward in the invocation stack (if needed)?

How about Error?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18159
    
    8

Originally posted by Joseph Sweet:
When code throws a RuntimeException, does the JVM look for a catch clause that might catch it?
Yes, the JVM always does that for all exceptions whether they are checked or not.
If it does, does it execute the finally clause before looking for a catch clause upward in the invocation stack (if needed)?
Yes, the JVM always executes a finally clause before leaving the block where an exception was thrown. Any kind of exception, checked or unchecked. And it doesn't matter what is going to happen higher up in the invocation stack afterwards, the exception processing is always the same.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18159
    
    8

Originally posted by Campbell Ritchie:
Jesper Young, I think Jonathan Sweet read about not throwing unchecked Exceptions
here, in the Java Tutorial.
Perhaps so. But that page is very far from saying "Don't throw unchecked exceptions".
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Actually, any Throwable (the direct superclass of Exception and Error). You can even make your own...

[ March 27, 2007: Message edited by: marc weber ]

"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36598
    
  16
Quoted by Paul Clapham:
Perhaps so. But that page is very far from saying "Don't throw unchecked exceptions".
I agree
Ricky Clarkson
Ranch Hand

Joined: Jul 27, 2006
Posts: 131
I recommend not catching Exception, Error or Throwable, and not doing nothing in a catch block. There are some times where this is intentional and good, but not many. Usually you're hiding problems.

You can think of exceptions as being another possible return type. int x() that throws Y is something that, kind of, returns either an int or a Y. If you make Y unchecked, you're saying that it's so abnormal for Y to be returned that it's not worth forcing the client programmer to handle it.

Checked exceptions are pretty good for robustness, but whether they're appropriate often depends on use cases. In my network simulator, if I get an IP address as text from a user, it makes sense for new IPAddress(String) to throw a checked exception, then I remember to handle the badly-formatted IP address. From my automated tests, it doesn't make sense to have to catch the exception, because I'm hard-coding an IP into the code anyway.

If you find that you're always catching the exception and wrapping it in a RuntimeException, perhaps you'd be better making the exception unchecked. You could even make two versions of a method; one with a checked exception and one without, though I'm not sure I'd recommend that. I do it in at least one place.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I recommend not catching Exception, Error or Throwable ...


Catching those generic types seems like the wrong thing to do, but I have very rarely found a need to write different reactions to different exceptions. One exception (!) was to distinguish a "page not found" from any other kind of rendering error in a web server so I could issue a 404 and show a special page, but that's really about the only one I can think of right now. Do you have any others?

Here's a common structure I really dislike:

unless I'm getting paid by the line.
Ricky Clarkson
Ranch Hand

Joined: Jul 27, 2006
Posts: 131
I do have some cases where I do different things based on the type of exception thrown. For example, an exception thrown because the input from a textfield was malformed tends to be treated differently to a NullPointerException.

Catching java.lang.Exception when you really meant to catch only SQLException, NumberFormatException, and a couple of others, means that you're taking the wrong lazy approach. Laziness is a good thing, being wrong isn't.

If you feel like you really mean catch (IOException | SQLException e), but you can't write that in Java, try to write the closest thing to it semantically, which is two catch blocks. catch (Exception) has different semantics to the above, including statically hiding any new checked exceptions that the code may suddenly start to throw, that may be better handled in another way.

Further, it handles RuntimeExceptions, and usually you don't want that. RuntimeExceptions are usually better handled by Thread.setDefaultExceptionHandler (if I remembered the API call correctly).
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I can't believe I'm saying this in public, but it's only "wrong" if the program doesn't work. Or or course if it causes pain in maintenance. I haven't been bitten by this bit of laziness yet. The one example for "file not found" involved a new exception type that didn't exist before. Adding another catch clause was not a painful experience. Reading past dozens of catch clauses that add absolutely nothing to the program is. I think we won't wind up agreeing here, which is perfectly fine on a Friday.
Ricky Clarkson
Ranch Hand

Joined: Jul 27, 2006
Posts: 131
If you were right, Stan, there would be no use in looking at code quality, ever. But code is not just about communicating with machines, but with humans too. catch (Exception) instead of two catch clauses tells me that you want to do the same thing with every exception that can possibly result from a piece of code, even exceptions that you haven't yet heard of.

I think you're expressing frustration at Java's exception syntax. I would rather that this were possible:

catch ((IOException || SQLException) exception)

The question would be what type exception would be, statically. The closest common superclass, in this case, Exception.

Personally I don't write code that (deliberately!) throws exceptions, because I don't like the repeated code that Java's syntax promotes. I instead include conditions (such as exceptions) in my return types. Here's a blog explaining one of the techniques: http://rickyclarkson.blogspot.com/2006/09/using-strong-typing-to-eliminate.html

It's particularly for nulls there, but stealing Haskell's Either type works well for other cases.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
If you were right, Stan, there would be no use in looking at code quality, ever.


Sure there is, because I included the pain of living with it. The other metric is the ongoing cost of defects, inflexibility, etc. I spent years fighting the attitude that any two programs that work are equal in quality, and still have to press the case now & then.

On this particular case, I've lived with code long enough to decide this has never hurt me. I invest a lot of effort in quality in areas that I have found to help me, but this one has yet to show me it's worth any more work.

The approach of handlers, callbacks or closures or whatever the language offers for exceptions and nulls and various optional paths is pretty neat. I like the idea of not having exceptions a lot.
 
jQuery in Action, 2nd edition
 
subject: Exception
 
Similar Threads
exception declaration
Exception test
Catch Exceptions when calling the super
Efficient Try Catch
Clarification about Exception handling