• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

About Exceptions

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why I have specify the Chencked Exceptions in my throws clause?
What is the special privilages that the UnChecked Exceptions have..?

Thx
Venkatesh
 
author & internet detective
Posts: 40791
828
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Venkatesh,
Welcome to JavaRanch!

Checked exceptions are specifically declared in the throws clause because the caller may want to do something in response. Checked exceptions are things that can be envisioned to happen. Unchecked exceptions are more of a surprise. They shouldn't happen (like a NullPointerException) so it isn't as likely that the caller will want to handle them.
 
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Venkatesh Ganesh:
Why I have specify the Chencked Exceptions in my throws clause?
What is the special privilages that the UnChecked Exceptions have..?



Checked exceptions are those that your application should cater for. It should be able to recover & handle such exceptions. Like, your application may be searching for a property file for initialisation, but if the property file is missing, an exception is thrown, the application could load a default property file instead.

For unchecked exceptions, usually the application can't handle or has no ways of recovering & it may not be advisable to proceed on any further. For example, when a database crashes, your application would not be able to connect to it, neither could it commit a transaction, so even if you catch that exception, you won't be certain that the integrity of your application is preserved, hence, usually they aren't caught & handled.
 
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think that the above description of the difference between unchecked and checked exceptions is OK, but the example is poor.

A database is generally a program that runs external to the Java application (yes, there are some Java databases, but...). In a distributed system like that, your Java code should expect there to be occasional problems contacting the external database and should be able to handle that in a reasonably sensible way. At the very least, it should do some logging and tell the user what happened, in a comprehensible message. It certainly shouldn't just let the exception percolate up to the top level and crash your Java program.

If some database-related exceptions are RuntimeExceptions, that's probably because there are many methods that can throw them and a lot of exceptions to list, and the API designer thought it would be tidier to have them as RuntimeExceptions. But that doesn't mean you don't have to deal with them properly.

In contrast, most of Java's built-in RuntimeExceptions are related to programmer errors (bugs). Examples include NullPointerException, IllegalArgumentException. You wouldn't expect to have specific handler code for that type of thing (except perhaps some top-level logging code). I think this is more the type of thing that RuntimeException is for.

However, I use CORBA a fair amount, and the CORBA API people decided that a lot of the common CORBA errors (COMM_FAILURE, OBJECT_NOT_EXIST...) should be RuntimeExceptions. That is more like how your database API is. But it doesn't mean that CORBA programs don't have to handle these errors. It just means they don't have to declare them all over the place, and that the compiler won't help you to determine whether they have been handled.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Venkatesh, be aware that there has been hot debate in the Java community about whether checked exceptions were a Good Thing or a Bad Thing. Bruce Eckel's book Thinking In Java has taken quite a turn on the subject from the first edition to the latest, and as I recall now provides a pretty balanced discussion of the pros & cons. You can see the 3rd edition online, but I think you'll have to pay for the 4th.

TIJ Free Download
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic