• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exception

 
Joseph Sweet
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Keith Lynn
Ranch Hand
Posts: 2409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you be specific about which exceptions you're throwing?
 
Joseph Sweet
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I throw an EJBException:

 
Keith Lynn
Ranch Hand
Posts: 2409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 327
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Right...
But why throwing an unchecked exception?
 
Keith Lynn
Ranch Hand
Posts: 2409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Joseph Sweet:
Right...
But why throwing an unchecked exception?


I'm not sure what you're asking.
 
Joseph Sweet
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aren't developers supposed to throw only checked exceptions?
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15205
36
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Campbell Ritchie
Sheriff
Posts: 48381
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Joseph Sweet
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Pie
Posts: 20729
30
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Pie
Posts: 20729
30
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, any Throwable (the direct superclass of Exception and Error). You can even make your own...

[ March 27, 2007: Message edited by: marc weber ]
 
Campbell Ritchie
Sheriff
Posts: 48381
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic