• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

exceptions

 
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
what is the difference between checked and unchecked exceptions?

As i know exceptions are conditions which occur at runtime,
then why such distinction between exceptions in first place?
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Because most RuntimeExceptions (NullPointerException, IllegalThreadStateException, NoSuchElementException, most occurrences of IllegalArgumentException) can be prevented by adding extra checks, whereas you can't check easily if your database is up and running (SQLException), for instance, or if your network is available, or your hard drive is broken (both IOException).

Granted, sometimes a preventable exception is still a checked exception (CloneNotSupportedException being the most annoying one), and I'm still wondering why FileNotFoundException exists*, but in most cases the rule is: if it can be prevented by adding checks it should be a RuntimeException, otherwise it should be a checked exception.


* there are two occurrences when a FileNotFoundException can be thrown:
- a file does not exist. But of course File.exists() can be used as a check.
- a file exists but cannot be opened as requested (e.g. trying to write to a read-only file). This could (should?) be handled with a regular IOException.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Prime wrote:- a file exists but cannot be opened as requested (e.g. trying to write to a read-only file). This could (should?) be handled with a regular IOException.


FileNotFoundException is a subclass of IOException, so if you catch IOException, you're also catching FileNotFoundException - i.e. you don't have to deal with it separately if you don't want to.
 
Rob Spoor
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
True, but that's beside the point. The point is, that I don't like the way the exception is used. Half of its purpose can be prevented, and for the other half the exception name is simply misleading. If I try to write to a read-only file I don't want a FileNotFoundException - I want a CannotWriteToFileException or something like that. Perhaps FileInaccessibleException.
 
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rajiv : The Java designers decided long ago that the compiler should be
used to enforce additional rules for some, but not all exceptions. Since
exceptions must be throwable, all exception types extend Throwable:
Throwable.Error(*) Throwable.Exception. And at the next level of the
exceptionheirarchy comes Throwable.Exception.Runtime(*).

The compiler does not enforce its "extra" rules for any exception of
the two types marked (*). All others, notably any extension of type
Exception, are examined more closely by the compiler. They are the
"checked" exceptions - as in "checked by the compiler".

Remember that it is just the two types, and their extensions, that are
the "unchecked" excpetions. If you throw a "new Throwable()" object,
for example, you will see the compiler do its extra checking.

Jim ... ...
 
my overalls have superpowers - they repel people who think fashion is important. Tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic