Exceptions

[Timo123]

Hi
ich habe eine Frage zu Exceptions. Mir ist noch nicht ganz klar, wann ich throw verwenden und wann nicht. Ich hab zwar gelesen, dass man runtime errors mit throw abfangen muss, aber was kann ich mir darunter vorstellen? Gibt es vlt eine einfache Merkregel?

Gruß Timo

 

[faetzminator]

throw = werfen, throws = wirft, catch = fangen.
Also macht man [c]throw new ...Exception(...)[/c] um eine Exception zu schmeissen.
[c]public void foo() throws ...Exception[/c] um anzugeben, dass eine (checked) Exception geschmissen wird.
[c]try { something(); } catch (...Exception e) { ... }[/c] um die Exception zu fangen und bearbeiten.
Siehe Galileo Computing :: Java ist auch eine Insel – 6 Exceptions

 

[Timo123]

Ich hab den Artikel schon vorher gelesen, jedoch war es mir immer noch nicht klarer.
Was sind checked und was unchecked Exeptions?
Wann benutze ich throw, wann catch?

Gruß

 

[faetzminator]

Was sind checked und was unchecked Exeptions?

Checked Exceptions müssen (leider) immer gefangen oder weitergeworfen werden. Z.B. wenn du eine Datei auslesen willst, könntest du eine [c]FileNotFoundException[/c] bekommen.
Eine unchecked Exception ist immer von [c]RuntimeException[/c] abgeleitet (das ist die Regel des Compilers) und könnte z.B. eine [c]NullPointerException[/c] sein.

Wann benutze ich throw, wann catch?

Hab ich dir bereits vorhin schon beantwortet: throw/throws zum schmeissen, catch zum fangen...

 

[AmunRa]

throw benutzt du immer wenn du eine aufrufende MEthode informieren möchtest, dass ein Fehler passiert ist.

Der Unterschied zwischen check und uncheck is nicht so einfach zu verstehen.

Also sehr einfach checked exceptions sind solche exceptions bei der der Programmierer bereits zum Zeitpunkt der Programmierung wissen kann, dass ein Fehler auftreten könnte. (z.B. Eine FileNotFoundException Der Programmierer kannbereits zum Zeitpunkt der Programmierung wissen, dass ein File nicht existieren könnte, weil z.B der User nicht das Recht hat den Ordner zu betrachten)

Diese müssen daher schon im SourceCode mit einem try/catch block umschlossen sein.

Uncheckexception sind eigentlich RuntimeException. Diese weisen oft eigentlich auf einen Programmierfehler hin.
z.B der häufigste Fehler NullPointerException. RuntimeException sollte nicht auftreten, da sonst eben der Programmierer einen Fehler gemacht hat und daher der SourceCode geändert gehört.

Einfaches Beispiel:

int i = new Scanner(System.in).nextInt();
int[] a= //hier wird ein Array mit int werten gefüllt;
System.out.println("Ihre Wahl war: "+a[i]);

Hier kann nun z.B. eine ArrayIndexOutofBoundsException auftreten, da der USer jeden int eineben kann.
wenn nun diese Excpetion fliegt, zeigt es einen Programmierfehler an, da der Programmierer nicht geprüft hat ob der wert den der User eingibt korrekt ist.

 

[faetzminator]

Also sehr einfach checked exceptions sind solche exceptions bei der der Programmierer bereits zum Zeitpunkt der Programmierung wissen kann, dass ein Fehler auftreten könnte. (z.B. Eine FileNotFoundException Der Programmierer kannbereits zum Zeitpunkt der Programmierung wissen, dass ein File nicht existieren könnte, weil z.B der User nicht das Recht hat den Ordner zu betrachten)

Diese müssen daher schon im SourceCode mit einem try/catch block umschlossen sein.

Uncheckexception sind eigentlich RuntimeException. Diese weisen oft eigentlich auf einen Programmierfehler hin.
z.B der häufigste Fehler NullPointerException. RuntimeException sollte nicht auftreten, da sonst eben der Programmierer einen Fehler gemacht hat und daher der SourceCode geändert gehört.

Das hätten die von Sun (bzw. nun Oracle) wohl gerne. Ich verwende selbst nie checked Exceptions, da ich das Konzept dessen einfach grausam finde. Normalerweise soll das Programm bei einem Fehler entweder einfach abschmieren oder die Fehler an einem zentralen Punkt geloggt werden. Zumindest ist das bei mir so.

 

[AmunRa]

Du hast schon recht das das Konzept von CheckedExceptions wie es sich Sun/Oracle vorgestellt haben nicht wirklich ankommt, aber meine Beschreibung glaub ich beschreibt trozdem den Unterschied recht gut. Ich selbst nimm auch immer wenn ich eine eigene Excption-Klasse schreibe eine RuntimeExcepiton als Basis. nur muss halt dann die Doku recht gut sein, damit man auch weiß, dass diese Exception geworfen werden kann.

 

[jgh]

btw was ist denn so grausam an dem Konzept des Exception-Handlings?

 

[faetzminator]

btw was ist denn so grausam an dem Konzept des Exception-Handlings?

Dass ich im Level 642 (vom Stack) mich nicht um eine Exception kümmern soll/will/muss, sondern das irgendwie in Level 20 gemacht werden soll. Wieso muss ich nun die Exception hundert Mal explizit weiterwerfen? Gibt sicher noch mehr Gründe dafür.

 

[AmunRa]

Zusätzlich weil manche Fehler einfach durch intelligente Programmierung nicht auftreten können, und warum sollte ich dann trozdem einen Try/catch Block machen?

 

[faetzminator]

Hab gerade noch ein Beispiel gefunden - sozusagen das Pendant zu AmunRas Idee: Was ist, wenn in einem Interface (oder einem sonstigen Supertyp) eine Methode abgeleitet werden soll, welche plötzlich eine Checked Exception weiterleiten muss?

interface I {
    void read();
}

class A implements I {
    public void read() throws FileNotFoundException {
        new FileReader(new File(""));
    }
}

Das hier kompiliert nicht. Ich würde es daher so lösen:

class A implements I {
    public void read() {
        try {
            new FileReader(new File(""));
        }
        catch (FileNotFoundException e) {
            throw new RuntimeException(e);
        }
    }
}

Uncool...!

 

[jgh]

Dass ich im Level 642 (vom Stack) mich nicht um eine Exception kümmern soll/will/muss, sondern das irgendwie in Level 20 gemacht werden soll. Wieso muss ich nun die Exception hundert Mal explizit weiterwerfen? Gibt sicher noch mehr Gründe dafür.

Also du musst sie ja nicht 100x eplizit weiterwerfen, catch und behandele sie...und wenn die Exceptions soviele Level nach oben geworfen werden, behaupte ich mal...sind auch andere Dinge im argen^^

Zusätzlich weil manche Fehler einfach durch intelligente Programmierung nicht auftreten können, und warum sollte ich dann trozdem einen Try/catch Block machen?

mag angehen...aber dann tut es auch nicht weh, einmal gleich einen catch-Block zu schreiben und nur den nicht mögliche ExceptionsStackTrace ausgeben zu müssen.

ich will mich ja auch nicht wieder so weit aus dem Fenster lehnen, wenn die Personen die mehr Erfahrung haben sagen, dass Exceptions schlecht sind, würde ich nur gerne wissen, warum?
Meine beschränkten Erfahrungen sagen mir, dass Exceptions eigentlich ganz nett zu programmieren sind.

Edit: zu faetzminator Beitrag:
ok, das ist natürlich nicht unbedingt schön, oder cool...aber who cares, das ist ja (hoffentlich) nicht der Regelfall?

 

[AmunRa]

nicht exceptions sind schlecht, sondern das konzept der checkedException ist fragwürdig. So ist j auch Java die einzige Programmiersprache die dies verwendet.

So weit ich mich erinnern kann gabs in der Plauderecke einen viele Seiten langen Thread zu diesem Thema, in dem schon viel darüber diskudiert wurde.

Ich würd auch sagen, dass wir diese diskussion hier beenden und wenn überhaupt dann wieder ein eigener Thread gestartet werden sollte, da diese Diskussion dem TO nicht hilft

 

[tfa]

@TO: In den FAQ steht ein Beitrag zum Thema Exceptions.
@jgh: Dort werden auch einige Probleme mit checked Exceptions dargestellt.

 

[Timo123]

Heißt das, wenn ich selber eine Exception Unterklasse erstelle ist diese checked und normale Exceptions wie NullPointerException usw. sind unchecked?

 

[TheDarkRose]

Wenn deine Exception von RuntimeException erbt, kannst du auch eine unchecked Exception erstellen

 

[Timo123]

Ja schon, aber die Standartexceptions sind alle unchecked?

 

[TheDarkRose]

Nein, was von Exception erbt, ist checked

 

[eRaaaa]

Ja schon, aber die Standartexceptions sind alle unchecked?

Nur die:

    AnnotationTypeMismatchException, ArithmeticException, ArrayStoreException, BufferOverflowException, BufferUnderflowException, CannotRedoException, CannotUndoException, ClassCastException, CMMException, ConcurrentModificationException, DataBindingException, DOMException, EmptyStackException, EnumConstantNotPresentException, EventException, IllegalArgumentException, IllegalMonitorStateException, IllegalPathStateException, IllegalStateException, ImagingOpException, IncompleteAnnotationException, IndexOutOfBoundsException, JMRuntimeException, LSException, MalformedParameterizedTypeException, MirroredTypeException, MirroredTypesException, MissingResourceException, NegativeArraySizeException, NoSuchElementException, NoSuchMechanismException, NullPointerException, ProfileDataException, ProviderException, RasterFormatException, RejectedExecutionException, SecurityException, SystemException, TypeConstraintException, TypeNotPresentException, UndeclaredThrowableException, UnknownAnnotationValueException, UnknownElementException, UnknownTypeException, UnmodifiableSetException, UnsupportedOperationException, WebServiceException

RuntimeException (Java Platform SE 6)

:bae:

 

[faetzminator]

Ja schon, aber die Standartexceptions sind alle unchecked?

Was heisst "Standardexception"? Alle in der J2SE API? Oben wurde doch bereits eine [c]FileNotFoundException[/c] als checked Beispiel genannt... Hier vollständigkeitshalber noch die Liste der checked Exceptions (in Java 6) :bae:

AclNotFoundException, ActivationException, AlreadyBoundException, ApplicationException, AWTException, BackingStoreException, BadAttributeValueExpException, BadBinaryOpValueExpException, BadLocationException, BadStringOperationException, BrokenBarrierException, CertificateException, ClassNotFoundException, CloneNotSupportedException, DataFormatException, DatatypeConfigurationException, DestroyFailedException, ExecutionException, ExpandVetoException, FontFormatException, GeneralSecurityException, GSSException, IllegalAccessException, IllegalClassFormatException, InstantiationException, InterruptedException, IntrospectionException, InvalidApplicationException, InvalidMidiDataException, InvalidPreferencesFormatException, InvalidTargetObjectTypeException, InvocationTargetException, IOException, JAXBException, JMException, KeySelectorException, LastOwnerException, LineUnavailableException, MarshalException, MidiUnavailableException, MimeTypeParseException, MimeTypeParseException, NamingException, NoninvertibleTransformException, NoSuchFieldException, NoSuchMethodException, NotBoundException, NotOwnerException, ParseException, ParserConfigurationException, PrinterException, PrintException, PrivilegedActionException, PropertyVetoException, RefreshFailedException, RemarshalException, SAXException, ScriptException, ServerNotActiveException, SOAPException, SQLException, TimeoutException, TooManyListenersException, TransformerException, TransformException, UnmodifiableClassException, UnsupportedAudioFileException, UnsupportedCallbackException, UnsupportedFlavorException, UnsupportedLookAndFeelException, URIReferenceException, URISyntaxException, UserException, XAException, XMLParseException, XMLSignatureException, XMLStreamException, XPathException