# Unterschied zwischen Checked und unchecked Exception



## AmunRa (16. Apr 2009)

Hallo nach dem wieder makl ein thread mit der throw Klausel im Umlauf ist ha sich für mich mal wieder eine Frage aufgetan.

Hab nach Google irgendwie keine Befriedigende Antwot auf die Frage was der Unterschied zwischen den Beiden Exceptions ist.

Schreib mal Kurz was ich alles Weis 

checkd Exceptions erben (indirekt)  von Exception
und unchecked Exceptions erben ( indirekt)  von  RuntimeException welche eigentlch wieder von Exception erbt.

oder lieg ich hier falsch?


RuntimeExceptions (=unchecked Exception) treten eigentlich nur zur Laufzeit auf und bedeuten nicht, dass das Programm fehlerhaft ist. 

So hier bekomme ich nun ein Problem. 
Was machen dann checked Exceptions? 
Wann treten diese auf?
Und wie soll/kann man mit diesen Umgehen?

Oder ist mein gesammter Ansatz schon falsch?

Danke schon mal

Michael


----------



## tfa (16. Apr 2009)

AmunRa hat gesagt.:


> checkd Exceptions erben (indirekt)  von Exception
> und unchecked Exceptions erben ( indirekt)  von  RuntimeException welche eigentlch wieder von Exception erbt.
> 
> oder lieg ich hier falsch?


Alles richtig.


> RuntimeExceptions (=unchecked Exception) treten eigentlich nur zur Laufzeit auf und bedeuten nicht, dass das Programm fehlerhaft ist.
> 
> So hier bekomme ich nun ein Problem.
> Was machen dann checked Exceptions?
> ...


Ursprünglich war es so gedacht: 

RuntimeException sollten auf Programmierfehler hin deuten (z.B. Versuch null zu dereferenzieren, ArrayIndexOutOfBounds etc). Sie sollten nicht gefangen und behandelt werden.

Checked Exceptions sind geplante Ausnahmesituationen, für die der Programmierer nichts kann, z.B. FileNotFound, ParseException und sowas. Die Java-Erfinder wollten die Programmierer zwingen, diese Exceptions entweder gleich zu behandeln, oder per throws zu deklarieren. Leider passiert es nur zu oft, dass man checked Exceptions eben nicht sinnvoll behandeln kann, sodass man sie sowie weiterwirft oder einfach verschluckt. Beides ist ärgerlich, letzteres sogar gefährlich.

Wie maki schon sagte, sind checked Exceptions out. Wenn man eine Lib oder API oder ein Framework entwickelt, sollte man ganz darauf verzichten.


----------



## Schandro (16. Apr 2009)

> RuntimeExceptions (=unchecked Exception) treten eigentlich nur zur Laufzeit auf und bedeuten nicht, dass das Programm fehlerhaft ist.


Doch, meistens bedeuten sie das das Programm fehlerhaft ist ;(
Es sind aber zu viele um sie alle einzeln aufzufangen, deswegen wird der Programmierer dazu nicht gezwungen.



> Was machen dann checked Exceptions?
> Wann treten diese auf?
> Und wie soll/kann man mit diesen Umgehen?


Wenn du eine Methode aufrufst, die explizit eine Exception schmeisst, musst du einen try-catch Block drumrumbauen oder diese wiederum weiterleiten:


```
public static int toInt(String string) throw NumberFormatException{
    return Integer.parseInt(string);
}

public static void main(String[] args){
    try{
        System.out.println(toInt("34b5")+12);
    }catch(NumberFormatException e){
        e.printStackTrace();
    }
}

public static void main(String[] args) throws NumberFormatException{
    System.out.println(toInt("34b5")+12);
}
```

Irgendwo müssen sie aber gefangen werden, außer in diesem Beispiel, da die main ja der anfang (die wurzel) dieses "Programmes" ist.

Achso: Checked Exceptions treten immer dann auf, wenn der Programmierer einer Methode lust darauf hatte, eine einzubauen 
meistens wenn es wahrscheinlich ist, das eine Exception auftritt bzw. wenn es wichtig ist das im Fehlerfall noch etwas bestimmtes passiert. (bei IO Sachen z.b. ...)


----------



## byte (16. Apr 2009)

Schandro hat gesagt.:


> Irgendwo müssen sie aber gefangen werden, außer in diesem Beispiel, da die main ja der anfang (die wurzel) dieses "Programmes" ist.



Genauer gesagt werden nicht behandelte Exceptions zuletzt vom UncaughtExceptionHandler des Threads behandelt, in dem die verursachende Methode aufgerufen wurde.


----------

