• Post Reply Bookmark Topic Watch Topic
  • New Topic

Order of listing exceptions  RSS feed

 
Mark O' Sullivan
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Just wondering when listing exceptions in a try catch block and one has 2 types of exceptions created.
(1) Runtime exceptions that extend exception
(2) exceptions that extend exception.
In what order should they be listed in the try catch block (2) before (1) or (1) before (2).
 
Paul Clapham
Sheriff
Posts: 22844
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you say "should" in your question, which authority are you asking about?
 
Rok Štelcer
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Hm, you will/should never catch any RuntimeException(s).
They usually represent a programmers bugs, improper use of an API, etc..

Anyhow, in general it is like this.
you should start with most specialized exception and end with the least one.
For example:
Bottom line, the parent class has to be catched after the class extending it.

Hope this helps.


Regards,
Rok
 
Paul Clapham
Sheriff
Posts: 22844
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, that isn't "should", that is "must". You MUST catch IOException before Exception because, as you say, IOException is a subclass of Exception. The compiler will require you to do it that way.

But if the question is about "should" then that might mean there is some style guideline, or something like that, which suggests that you SHOULD put your catch clauses in some particular order, even if the compiler doesn't care. That's why I asked Mark who or what was dictating this "should".
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rok Štelcer wrote:Hm, you will/should never catch any RuntimeException(s).

Strongly, strongly disagree. It may be wise to avoid catching them, especially if you're not sure what you're doing. But saying "always" here is horrible advice, in my opinion. Catch the exceptions that need catching, at the point they need to be caught. Don't let simplistic rules get in the way.

Rok Štelcer wrote:They usually represent a programmers bugs, improper use of an API, etc..

Often this is true. However there are exceptions to this - most notably, if you use Spring or Hibernate, then pretty much all exceptions thrown by these tools are RuntimeExceptions. People using these tools need to occasionally catch such exceptions, or their programs will crash and burn. Yet somehow, many successful projects have been implemented using these tools.

The whole concept of checked exceptions seems to be unique to Java, not required by any other languages I know of. And even within Java, there are plenty of people who have decided it was a bad idea in the first place, and have rejected it by designing frameworks and APIs that do not use checked exceptions. There are also plenty of people who still think think the concept of checked exceptions is useful. There's been quite a lot of debate over this, and no real consensus. Brian Goetz gives a good overview of the topic and debate here. Follow links in the "resources" section for many more views on the topic.

Fundamentally, even if you're deeply convinced that checked exceptions are a good thing, and write all your code with this philosophy, and all the people you work with share your views on this... at some point, you may find yourself working with a third-pary library that does not follow this paradigm. At that point, you can either rewrite the entire library... or bite the bullet, and learn to catch unchecked exceptions. Maybe even (gasp) Errors. Really. It's OK. The world does not explode or anything. You may even get better error logging, because you're no longer afraid to catch something just so you can log useful information about it.
 
Rok Štelcer
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi @,

Mike Simmon wrote:Rok Štelcer wrote:Hm, you will/should never catch any RuntimeException(s).


Strongly, strongly disagree. It may be wise to avoid catching them, especially if you're not sure what you're doing. But saying "always" here is horrible advice, in my opinion. Catch the exceptions that need catching, at the point they need to be caught. Don't let simplistic rules get in the wa

Perhaps I'm too little open minded or too conservative ... anyhow, this's my point of view.

Mike Simmons wrote:Often this is true. However there are exceptions to this - most notably, if you use Spring or Hibernate, then pretty much all exceptions thrown by these tools are RuntimeExceptions

I have to admit that I'm not familiar with springs, hibernate and others, meaning that I can't really post any comment on this.
However the theory is clear, and I don't really care how others are using it ...
Hm, perhaps we misunderstood each other ...
I'm for example a JavaSE developer, and when writing APIs, I also use rte (e.g. IllegalArgumentException) extensively.
However when someone is calling my API, he should never try to catch it (it is always documented in the javadoc how to avoid it).

In case it is not or perhaps badly documented, this is another story ...

Mike Simmon wrote:...at some point, you may find yourself working with a third-pary library that does not follow this paradigm. At that point, you can either rewrite the entire library..

I totally agree on this one ... however I would have to say that not every 3rd party product is mature for usage ... sometimes is better to rewrite it.
Of course this depends on the size and lifetime of your project/product.
I'm working e.g. on a very large GUI (fat client, a small ;) part of a very large product) which is and will be around for a quite of few years (even a decade).
Well, this is my background ... ;)


Regards,
Rok
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!