39

I am a C# developer doing occasional coding in Java. Can someone explain in simple terms what are checked exceptions in Java and why is it needed? Haven't come across this term in C#.

blitzkriegz
  • 9,258
  • 18
  • 60
  • 71
  • possible duplicate of [Why must only certain Exceptions be declared as thrown in method signature](http://stackoverflow.com/questions/3755203/why-must-only-certain-exceptions-be-declared-as-thrown-in-method-signature) – OhadR Apr 20 '14 at 16:04
  • 1
    checked exceptions in Java is violation of Open/Closed Principle.You must declare that exception in the signature of each method between you and the catch. – naeemgik Oct 31 '19 at 05:19
  • For C#, you can check the following link https://github.com/AminEsmaeily/Portia.Roslyn.CheckedException – Amin Aug 23 '21 at 03:56

3 Answers3

70

Checked exceptions are exceptions that the compiler require you handle in some way.

In Java, checked exceptions are Throwables that are not RuntimeException, Error, or one of their subclasses.

The Java designers felt they were needed to ensure programs handled exceptions that were reasonably likely. A classic example is IOException. Any time a program does I/O, there is a possibility of failure. The disk could be full, the file might not exist, there might be a permissions problem, etc.

Thus, Java is designed such that a program must syntactically handle the exception in some way. This could be with a catch block, or by rethrowing the exception in some way.

C# does not have checked exceptions. They decided to leave this issue up to the application developers (interview). Checked exceptions are controversial because they can make code verbose, while developers sometimes handle them trivially with empty catch blocks. Further, it can be arbitrary which standard library methods throw checked exceptions. For instance, why doesn't File.delete (a new Java 7 API does this differently) throw IOException?

Another concern Hejlsberg noted in that interview is versionability. Adding a checked exception to a throw clause forces all code using that method to be modified and recompiled.

Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539
  • 9
    `Adding a checked exception to a throw clause forces all code using that method to be modified and recompiled` - so you have for unchecked exceptions. Well, except if you think `Will fail under some circumstances` is how you'd like to describe your API. EVERY exception is part of the public interface of a method, adding ones later is like saying "Oh and from now on that int parameter will have a completely different semantic meaning - but don't worry, it's still binary compatible!" – Voo Feb 21 '12 at 03:52
  • 3
    @Voo, this is discussed specifically in [this part](http://www.artima.com/intv/handcuffs2.html) of the interview. Hejlsberg argues that not every exception actually needs to be handled by the immediate calling code. He says some are best handled by the main message handler, even if that main handler wasn't written with specific knowledge of the new exception. – Matthew Flaschen Feb 21 '12 at 03:57
  • 2
    Imo he uses a bad library example. If I write a library that I expect to change later I'll have to have it's methods throw an abstract enough exception (eg some generic datahandler class that throws an SqlException clearly violates this principle). Then if I want to I can add other subclasses later on, which gives similar possibilities, but has similar downsides. So yes I agree Java's checked exception handling has problems (got better with 7 wrt to boilerplate code though), [cont] – Voo Feb 21 '12 at 04:09
  • 2
    but I think only unchecked exceptions mislead programmers to ignore error cases and make changes to their APIs that break compatibility to earlier versions. I've seen so much C# code that does this and documents the thrown exceptions badly at best I just don't think this is a better way. On the other hand I see almost nobody in the last few years doing `throw Exception` in Java - that has quite a stigma on it I think. But yes I'm still hoping for some solution that allows us to cut down on the boilerplate necessary for checked exceptions without the downsides of unchecked ones. – Voo Feb 21 '12 at 04:12
  • @Voo: What I think I'd like to see would be a means of specifying declaratively that particular exceptions thrown from within code *called by* a method or block should be wrapped as something else (either `RunTimeException`, or a specified alternative). If code won't be able to do anything useful if e.g. a file needed for decoding a document can't be found, forcing that code to catch the exception won't help anything. Having checked exceptions bubble up as their same type may be unhelpful, since a caller may think a `FileNotFoundException` means the *document* wasn't found. – supercat Feb 01 '13 at 07:40
  • What if we specified that our method will through 2 exceptions but somehow the third exception was throw "unintentionally" due to poor implementation or we make call to another method and it throws exceptions etc. It is tendous to try to list all the exceptions in the function declaration. And for this particular case it sound like a fale promise, isn't it? – c.sokun Apr 01 '14 at 11:18
  • @c.sokun, if the third exception is a checked exception, it is impossible to make such as "false promise". You would have to document that it can be thrown, or it could not be thrown. – Matthew Flaschen Apr 02 '14 at 05:38
  • " Checked exceptions are controversial " By 2017 standards, they are not controversial, but just plain wrong and must be avoided. – earizon Dec 12 '17 at 17:11
  • Checked exceptions syntax in Java has become a problem more recently. Brian Goetz (Java Architect) added at the bottom of [this answer](https://stackoverflow.com/a/27668305/8109319) that there's no work on fixing interactions with lambdas and checked exceptions which is real annoying. – kmui2 May 01 '20 at 16:43
6

In Java, a checked exception (as Matthew Flaschen correctly points out) is an exception that the compiler requires you to handle. These are exceptions that are declared on function definitions (e.g. function bob() throws ImNotBobException { ... } to say that calling that function may throw that exception - e.g. NumberFormatException when parsing an integer, or IOException when writing to a file.

However, some exceptions can be thrown from unknown or unexpected places that are simply impractical to handle on every level, so the compiler does not require you to handle these. These are unchecked exceptions. They can be thrown from various places that do not declare to throw them (often by attempting to call a method on an object when that object has not been initialised yet, i.e. is null - this will result in a NullPointerException.)

Hope this helps.

Fritz H
  • 3,539
  • 2
  • 26
  • 37
0

Checked exceptions are exceptions that require any "consuming" class to have to code that explicitly checks (and hopefully handles) the exception.

For example, if the Apple class has an Eat() method which includes the checked exception of WormFound then any code that calls that method will need to explicitly have a catch for that exception.

As a side note, it is feature of Java and not of C#.

(At the point when C# was created, the pros of checked exceptions weren't so obvious in the eyes of the C# team so they weren't included.)

lzcd
  • 1,325
  • 6
  • 12