Sinn von RuntimeExceptions?

[hdi]

Hey Jungs..

ich wollte gerade jmd erklären wofür genau Exceptions da sind und wie man sie benutzt. Dabei musste ich feststellen dass mir die RuntimeExceptions (also unchecked) selbst ein Rätsel sind.

Erstmal hoffe ich dass ich zumindest die checked Exceptions verstehe: checked Exceptions machen Sinn da man zur Compile-Zeit sicherstellt dass auf mögliche kritische Situationen (zB falsche User-Eingabe) reagiert wird. Und hauptsächlich ist der Vorteil davon einfach nur dass ich durch das Exception Handling entscheiden kann, wo genau man auf so eine Situation reagiert (Weiterreichen per throw - ich möchte in der Methode nicht konkret entscheiden wie reagiert wird, u.U. kann ich das dort gar nicht)

Ich hoffe das hab ich richtig verstanden?

Aber jetzt zu unchecked: Was soll das? Es wird nicht sichergestellt dass man darauf reagiert, man weiss oft gar nicht dass dieser Fehler auftreten kann, und alles was es tut ist ne Message anzuzeigen und den Thread zu killen. Letztendlich läuft meine Frage auf folgendes hinaus:

Warum

throw new RuntimeException();

statt:

System.err.prnitln("Fehler blablabla");
System.exit(-1); // bzw nur den Thread killen

Macht doch das gleiche? Und der Aufrufer hat doch eh keine Ahnung bei ner RuntimeException dass sie auftreten kann, wenn er nicht zufällig in den Source schaut??
Also ich glaub ich hab das mit den Exceptions noch nicht wirklich verstanden.. benutz es wie gesagt selber eig. gar nicht.

lg

 

[bygones]

Leider nicht immer garantiert

sollte aber - ansonsten wird das stueck API nicht akzeptiert

dem kann ich gerade absolut nicht folgen, meiner Meinung nach sage ich soviel wie: "Behandle jede Krankheit und gib für evtl. fälle ein nette Impfung die den Ausbruch verhindern kann"

ich versuchs mit einem anderen Versuch

mit dem Verwender von checked Exceptions anstatt einem sinnvollen Design argumentierst du dass es dadurch erst auffaellt, weil das andere moeglicherweise unentdeckt bleibt.

Also wenn du ein kleines Loch in der Strasse findest reparierst du es nicht, sondern machst ein noch groesseres Loch, damit die anderen das auf alle Faelle sehen

vll sollte ich diese Vergleichssachen lassen ;-)

Sinn: du behandelst die Krankheit nicht durch Einfuehren eines Serums sonder durch Einfuehren einer groesseren Krankheit

 

[Tomate_Salat]

Was füßr einen Stacktrace denn??
Wir reden auch von Exceptions die gar nicht auftreten können, wo der try/catch Block nur vom interface (throws <irgendeine checked Exception>) erzwungen wird.
Möchtest du dazu ein Beispiel?

An die interfaces hab ich nicht gedacht. Wie sinnvoll es ist, dass die eine exception erzwingen können halte ich auch für fragwürdig.

Deine Behauptung dass RTEs so gemeint waren stammt vielleciht daher dass du den Text falsch verstanden hast, aber Fakten gibt es keine dafür.

Ok in der tat, das Argument ziehe ich zurück.

Die Meinungen zum GOTO-Statement

Da teile ich durchaus die Meinung

sollte aber - ansonsten wird das stueck API nicht akzeptiert

nette Einstellung

ich versuchs mit einem anderen Versuch

mit dem Verwender von checked Exceptions anstatt einem sinnvollen Design argumentierst du dass es dadurch erst auffaellt, weil das andere moeglicherweise unentdeckt bleibt.

Das ist durchaus sinnvoll, bis auf das Interfaces Exceptions erzwingen können, hier stimme ich mit ein.

Sinn: du behandelst die Krankheit nicht durch Einfuehren eines Serums sonder durch Einfuehren einer groesseren Krankheit

Lass mich raten, die checked Exception ist die größere Krankheit?!

 

[Landei]

da kannst du auch gleich anführen: [c];[/c] sind unnötig, python hat keine und soweit ich gesehen habe (korrigiert mich wenn ich falsch liege) Scala auch nicht.

Korrektur: Scala hat Semikolons, man muss sie nur nicht immer schreiben (auch Google's Go macht es so). Die Regel ist so in etwa: Immer wenn man am Zeilenende ein Semikolon setzen könnte, ohne dass es ein Syntaxfehler wäre, dann denkt sich Scala eins.

 

[Tomate_Salat]

Korrektur: Scala hat Semikolons, man muss sie nur nicht immer schreiben (auch Google's Go macht es so). Die Regel ist so in etwa: Immer wenn man am Zeilenende ein Semikolon setzen könnte, ohne dass es ein Syntaxfehler wäre, dann denkt sich Scala eins.

Ah ok, hab mich bewusst zurückhaltend ausgedrückt. Kenne Scala bislang nur von den Code-Examples

 

[SlaterB]

ich versuchs mit einem anderen Versuch

mit dem Verwender von checked Exceptions anstatt einem sinnvollen Design argumentierst du dass es dadurch erst auffaellt, weil das andere moeglicherweise unentdeckt bleibt.

Also wenn du ein kleines Loch in der Strasse findest reparierst du es nicht, sondern machst ein noch groesseres Loch, damit die anderen das auf alle Faelle sehen

vll sollte ich diese Vergleichssachen lassen ;-)

Sinn: du behandelst die Krankheit nicht durch Einfuehren eines Serums sonder durch Einfuehren einer groesseren Krankheit

wenn es darum geht eine einzelne Stelle der Doku zu reparieren stimmt der Vergleich, aber darum gehts ja nicht,

mit Unchecked Exceptions hat man für alle Zukunft unbehandelbar diverse Gefahren:
1. bei jedweger neuer Doku oder Codeänderungen kann ständig die Angabe der Exceptions vergessen werden
2. jeder Anwender des Codes kann vergessen, in die API zu schauen, darauf zu achten
3. bei korrekter Änderungen des Codes + der Doku dazu sind alte Zugriffe darauf nicht betroffen, man müsste sie manuell abklappern und schauen ob was zu tun ist,

aus systematischer Sicht sind Unchecked Exceptions also die Katastrophe, etwa so undurchsichtig wie Rückgabewert int und -1 hat auf einmal eine neue Bedeutung

Unchecked Exceptions bieten in der Gesamtsicht ein einfacheres souveränes Handling,
wenn man nur die Technik-Aspekte betrachtet sind sie aber überhaupt nicht eingebunden, Doku ist purer Text, noch weniger wichtig als Annotations

Checked Exceptions passen dagegen perfekt ins Signaturbild, leider mit diversen Problemen verbunden

 

[byte]

Ohne Javadoc weisst Du auch bei Checked Exceptions nicht, warum sie auftreten, ausser Du guckst in die Sourcen.

 

[Tomate_Salat]

Also wenn ich eine FileNotFoundException bekomme, kann ich mir vorstellen, woher der Fehler kommt ;-)
und SlaterB hat ja nicht gesagt, dass man JavaDoc abschaffen soll

 

[byte]

Du kannst es erraten, weisst es aber nicht mit Sicherheit. Was ist, wenn z.B. eine SqlException fliegt und Du keine Javadoc hast?

Nur im trivialen Fall, kann man anhand des Exception Namens erraten, was schief gelaufen ist.

 

[AmunRa]

Ich hab mir jetzt grad die ganze Diskussion durchgelesen, und immer weider wurde auf das problem hingewiesen, das man durch die checked exceptions gezwungen wird darauf zu reagieren auch wenn man nicht kann.

Stimmt doch nicht ganz. (Oder?)

mit throws könnte man doch die Exception ja soweit nach oben werfen bis man reagieren kann (bzw. Wenns gar nicht geht throwed man sie halt in der main noch raus. Weil dann hat das Programm ja wirklich einen Fehler der nicht behandelt werden kann. (Programierfehler);

 

[byte]

@AmunRa - Das ist keine Lösung, denn damit versaut man sich die Interfaces.

 

[SlaterB]

Du kannst es erraten, weisst es aber nicht mit Sicherheit. Was ist, wenn z.B. eine SqlException fliegt und Du keine Javadoc hast?

Nur im trivialen Fall, kann man anhand des Exception Namens erraten, was schief gelaufen ist.

Warum ist kein technisches Argument und spielt beim grundsätzlichen Punkt 'Vergessen' auch keine echte Rolle,
das Checked an einer Exception ist wie ein zusätzlicher Parameter an einer Methode,

er kann unmöglich ignoriert werden, außer wenn man aktiv null/ 0 übergibt,
er muss nicht dokumentiert werden sondern all sein Sinn ist in der Signatur fest vorgegeben,

dass man sich auch bei neuen Parametern dann nach dem Warum fragt und hoffentlich in der Doku was findet
ist genauso nebensächlich, der nächste Schritt

 

[tfa]

@AmunRa:
Das ist auch eine "Behandlung" (im Sinne von Reaktion) auf die checked Exceptions. Du musst unzählige Methoden anfassen und hast am Ende sowas wie

[c]myMethod() throws SQLException, PersistenceException, RemoteException, IOException, GUIException [/c]

 

[Tomate_Salat]

Du kannst es erraten, weisst es aber nicht mit Sicherheit. Was ist, wenn z.B. eine SqlException fliegt und Du keine Javadoc hast?

Nur im trivialen Fall, kann man anhand des Exception Namens erraten, was schief gelaufen ist.

Ich glaube mir ist noch kein Fehler aufgetreten, dessen Ursache ich nicht am Namen erkenne konnte....und jetzt mal ne entscheidende gegenfrage: Wer sagt den, dass keine Javadoc vorhanden ist?! Was ist wenn man bei unchecked keine Javadoc hat? Da ist man doch mit der checked auf der wohl wesentlich sicheren Seite (ich verweise hier mal auf die gefahrenaspekte von SlaterB's post)

@AmunRa - Das ist keine Lösung, denn damit versaut man sich die Interfaces.

Danke, den viele unchecked Exceptions werden wohl das gleiche Schicksal erleiden, wie Exceptions die aus der main gekickt werden ;-)

 

[byte]

Warum ist kein technisches Argument und spielt beim grundsätzlichen Punkt 'Vergessen' auch keine echte Rolle,
das Checked an einer Exception ist wie ein zusätzlicher Parameter an einer Methode,

er kann unmöglich ignoriert werden, außer wenn man aktiv null/ 0 übergibt,
er muss nicht dokumentiert werden sondern all sein Sinn ist in der Signatur fest vorgegeben,

dass man sich auch bei neuen Parametern dann nach dem Warum fragt und hoffentlich in der Doku was findet
ist genauso nebensächlich, der nächste Schritt

Verstehe Deine Argumentation mal wieder nicht, aber das kommt ja häufiger vor.

Checked Exceptions zwingen Dich, sie zu fangen und zu behandeln. Wenn ich sie behandeln will, muss ich wissen, wann sie fliegen. Das steht nur in der Javadoc oder in den Sourcen.

Fazit: Ich muss als Entwickler in die Javadoc (oder Sourcen) gucken, um Exceptions zu behandeln, ganz egal ob Checked oder Unchecked.

Deine Argumente gegen Unchecked Exceptions sind somit irrelevant.

 

[Tomate_Salat]

Checked Exceptions zwingen Dich, sie zu fangen und zu behandeln. Wenn ich sie behandeln will, muss ich wissen, wann sie fliegen.

man weis bei welchem aufruf sie geschmissen werden können ...

Das steht nur in der Javadoc oder in den Sourcen.

Das hast du nicht ernsthaft gerade als Argument gegen checked exceptions gebracht oder?!

Fazit: Ich muss als Entwickler in die Javadoc (oder Sourcen) gucken, um Exceptions zu behandeln, ganz egal ob Checked oder Unchecked.

Deine Argumente gegen Unchecked Exceptions sind somit irrelevant.

nicht wirklich

 

[byte]

man weis bei welchem aufruf sie geschmissen werden können ...

OK, dann sag mir was passieren muss, damit eine beliebige Implementierung dieser Methode eine SqlException schmeisst:

interface MyDao {
  public User getUser(Long id) throws SqlException;
}

 

[Tomate_Salat]

An die interfaces hab ich nicht gedacht. Wie sinnvoll es ist, dass die eine exception erzwingen können halte ich auch für fragwürdig.

Habe bereits mitgeteilt, dass ich den Sinn auch nicht nachvollziehen kann, warum ein Interface einen Exceptionwurf veranlassen kann.

 

[tfa]

Habe bereits mitgeteilt, dass ich den Sinn auch nicht nachvollziehen kann, warum ein Interface einen Exceptionwurf veranlassen kann.

Weil es checked Exceptions gibt! ;(

 

[byte]

Habe bereits mitgeteilt, dass ich den Sinn auch nicht nachvollziehen kann, warum ein Interface einen Exceptionwurf veranlassen kann.

Kein Problem. Dann sag mir einfach, was passieren muss, damit diese Methode eine SqlException schmeisst (ohne Javadoc und Sourcecode zu kennen):

class MyDao {
  public User getUser(Long id) throws SqlException { /* unbekannt */ };
}

 

[SlaterB]

Fazit: Ich muss als Entwickler in die Javadoc (oder Sourcen) gucken, um Exceptions zu behandeln, ganz egal ob Checked oder Unchecked.

stell dir vor, dieses 'Unchecked'-Verfahren würde auch in anderen Bereichen durchgesetzt, etwa bei den Methoden-Parametern oder im Typ-System,

jeder könnte
Collections.sort();
aufrufen, oder auch
Collections.sort(string);
Collections.sort(string, string, int, liste);
oder sonst was beliebiges,
es würde nicht geprüft werden, wieviele Parameter, welchem Typ usw.,
jeder falsche Aufruf wäre erlaubt und führt (ironischerweise) zu einer RuntimeException

das Chaos wäre perfekt,
dein Argument 'kann man doch alles in Javadoc oder Source nachschauen' würde hier genauso gelten,

nein, es gibt techische Mechanismen, Signatur-Check, Anzahl Parameter, Typsicherheit, die hier diverse Probleme sofort dem Compiler sichtbar machen,
auch wenn in Java 1.7 der sort()-Methode ein neuer Parameter hinzugefügt wird sind sofort alle nicht mehr funktionierenden Stellen im Code sichbar

genau diesen Komfort bieten Checked Exceptions gegenüber Unchecked, technische Mechanismen statt beliebiger nur von Menschen interpretierter Doku,
ob das ausreicht um sich all die anderen Probleme aufzuhalten ist eine andere Frage, die offensichtlich überwiegend mit Nein zu beantworten ist,
aber dieses Argument bleibt so bestehen

Deine Argumente gegen Unchecked Exceptions sind somit irrelevant.

ein trauriger Argumentationsstil, wie man ihn von manchen hier sieht (maki usw),
für mich unverständliches zwischenmenschliches Verhalten

 

[Tomate_Salat]

Weil es checked Exceptions gibt! ;(

nein, an und für sich ist an checked Exceptions nichts auszusetzen außer in Punkto Interface

 

[maki]

Checked Exceptions passen dagegen perfekt ins Signaturbild, leider mit diversen Problemen verbunden

Diese diversen Probleme wiegen leider mehr als die von die genannten Vorteile SlaterB, checked Exceptions waren anfangs eine schöne Idee, allerdings hat die Praxis die unschönen Seiten aufgezeigt, welche leider alle Vorteile überwiegen.

 

[tfa]

nein, an und für sich ist an checked Exceptions nichts auszusetzen außer in Punkto Interface

Du hast nicht verstanden. Weil es checked Exceptions gibt, müssen diese auch in den Interfaces deklariert werden. Sonst würde das ganze Konstrukt überhaupt nicht funktionieren.

 

[Tomate_Salat]

Kein Problem. Dann sag mir einfach, was passieren muss, damit diese Methode eine SqlException schmeisst (ohne Javadoc und Sourcecode zu kennen):

class MyDao {
  public User getUser(Long id) throws SqlException { /* unbekannt */ };
}

Lol, willst du darauf hinaus dass man in dem Falle in die docs schauen muss? Lachhaft, sorry, aber für unchecked musst du für ALLE in docs schauen, weil einfach ALLES möglich ist was geschmissen werden kann. Du argumentierst mit etwas was bei unchecked exceptions das wesentliche Problem ist?!
:toll: danke dass du meine Meinung unterstützt :applaus:

Du hast nicht verstanden. Weil es checked Exceptions gibt, müssen diese auch in den Interfaces deklariert werden. Sonst würde das ganze Konstrukt überhaupt nicht funktionieren.

Kein System ist perfekt. Aber ich sags mal so: ist mir immernoch lieber als wie wenn alles unchecked wäre. Solche Konstrukte sollte man halt als Entwickler einer API umgehen.

 

[byte]

Lol, willst du darauf hinaus dass man in dem Falle in die docs schauen muss? Lachhaft, sorry, aber für unchecked musst du für ALLE in docs schauen, weil einfach ALLES möglich ist was geschmissen werden kann. Du argumentierst mit etwas was bei unchecked exceptions das wesentliche Problem ist?!
:toll: danke dass du meine Meinung unterstützt :applaus:


Kein System ist perfekt. Aber ich sags mal so: ist mir immernoch lieber als wie wenn alles unchecked wäre. Solche Konstrukte sollte man halt als Entwickler einer API umgehen.

Herzlichen Glückwunsch. Du hast verstanden, worauf ich seit Stunden hinaus will. Um Exceptions zu behandeln, muss man wissen, unter welchen Umständen sie fliegen. Dafür muss man in die Javadoc oder die Sourcen gucken, völlig egal ob Checked oder Unchecked. Der Compilecheck bei Checked Exceptions bringt mir also überhaupt keinen Mehrwert.

 

[maki]

Aber ich sags mal so: ist mir immernoch lieber als wie wenn alles unchecked wäre. Solche Konstrukte sollte man halt als Entwickler einer API umgehen.

Speziell als API Entwickler muss man checked Exceptions vermeiden...

 

[Tomate_Salat]

Herzlichen Glückwunsch. Du hast verstanden, worauf ich seit Stunden hinaus will. Um Exceptions zu behandeln, muss man wissen, unter welchen Umständen sie fliegen. Dafür muss man in die Javadoc oder die Sourcen gucken, völlig egal ob Checked oder Unchecked. Der Compilecheck bei Checked Exceptions bringt mir also überhaupt keinen Mehrwert.

Du aber offensichtlich nicht, das war mir schon von anfang an klar. Aber ich hab bisher noch nie für eine Exception in die docs schauen müssen. Mir war bisher immer klar, woher der Fehler kam! Das wäre bei unchecked anderster. Bei unchecked exceptions muss ich sogar noch nachschauen, welche Methoden oder gar Konstruktoren anfällig sind und muss trotzdem drauf reagieren...Dabei hab ich nichts gewonnen außer die Erlaubnis, mal die ein oder andere Exception zu übersehen.

Speziell als API Entwickler muss man checked Exceptions vermeiden...

Bin ich anderer Meinung

 

[byte]

Aber ich hab bisher noch nie für eine Exception in die docs schauen müssen. Mir war bisher immer klar, woher der Fehler kam!

Na das erklärt einiges...

 

[maki]

Bin ich anderer Meinung

Tomate_Salat,

du scheinst extrem Betratungsresistent zu sein heute.

Naja, manche wollen ihre Erfahrungen eben auf die harte Tour machen, es gibt genug Infos & Doks im Internet die die erklären könnten warum deine Meinung falsch ist, ist weder neu noch ein Geheimnis, aber dazu müsstest du erstmal anfangen Argumente anzunehmen.

Aber ich hab bisher noch nie für eine Exception in die docs schauen müssen. Mir war bisher immer klar, woher der Fehler kam!

Lass mich raten: Der Fehler kam von "vor dem Bildschirm" *g*

Jedem das seine...

 

[Tomate_Salat]

du scheinst extrem Betratungsresistent zu sein heute.

Sorry, bei euren Argumenten bin ich noch mehr von den checked Exceptions überzeugt. Ich fasse mal zusammen was bei mir hängen geblieben ist:

• ich bin zu faul auf jede Exception zu reagieren
• man muss Exceptions in den docs nachschauen (was wohl eher auf unchecked zutrifft)
• checked exceptions sind en designfehler und böse
• Aber in der Programmiersprache XYZ ists auch nicht

gute Argumente gegen checked Exceptions, muss ich schon sagen :applaus:

Unchecked ist einfach ein abartiges Sicherheitsrisiko, wer Faulheit über Sicherheit stellt...naja

Argumente anzunehmen.

bring mir welche

Lass mich raten: Der Fehler kam von "vor dem Bildschirm" *g*

nettes Niveau ;-)

 

[tfa]

Manche Leute machen Borniertheit zu einer Wissenschaft.

 

[maki]

Sorry, bei euren Argumenten bin ich noch mehr von den checked Exceptions überzeugt. Ich fasse mal zusammen was bei mir hängen geblieben ist:

• ich bin zu faul auf jede Exception zu reagieren
• man muss Exceptions in den docs nachschauen (was wohl eher auf unchecked zutrifft)
• checked exceptions sind en designfehler und böse
• Aber in der Programmiersprache XYZ ists auch nicht

gute Argumente gegen checked Exceptions, muss ich schon sagen :applaus:

Unchecked ist einfach ein abartiges Sicherheitsrisiko, wer Faulheit über Sicherheit stellt...naja



bring mir welche



nettes Niveau ;-)

Blätter doch mal ein paar Seiten zurück, lies deine Posts in denen du..
- behauptet hast RuntimeExceptions wären schlechter Programmierstil
- dir Argumente aus den Fingern gesaugt hast
- nicht verstanden hast worum es geht

usw.

Ich denke ehrlich gesagt dass du immer noch nicht weisst worum es geht und eigentlich hab ich den Eindruck dass dir das gar nichts ausmacht.

Damit beende ich die "Diskussion" von meiner Seite, lieber rede ich mit einer Wand, denn diese versteht offensichtlich genausoviel von der Thematik, ist aber nicht so stur.

 

[byte]

Ich denke ehrlich gesagt dass du immer noch nicht weisst worum es geht und eigentlich hab ich den Eindruck dass dir das gar nichts ausmacht.

Wenn ich mir den Sourcecode in seinem Blog so angucke, denke ich das auch.

@Tomate_Salat - Ist das Deine Vorstellung von Exception Handling? Dann brauchen wir hier gar nicht weiterdiskutieren.

    public void closeZIPArchive()
    {
        if(ZIP_STREAM != null)
        {
            try 
            {
                ZIP_STREAM.close();
                finalize();
            }
            catch (Exception e) 
            {       
                e.printStackTrace();
            }
            catch (Throwable e) 
            {
                e.printStackTrace();
            }
        }
    }

 

[Tomate_Salat]

Auch wenn ich bei der verwendung von RuntimeExceptions falsch gelegen habe, mag ich sie trotzdem nicht in einer API haben, ich weis worum es geht und der rest war nicht aus den fingern gezogen. Letztendlich steht doch noch die nette Argumentliste von SlaterB im Raum zum Thema Sicherheitsrisko bei unchecked Exceptions, was hier warum auch immer total von euch ignoriert wurde ;-)

@Tomate_Salat - Ist das Deine Vorstellung von Exception Handling? Dann brauchen wir hier gar nicht weiterdiskutieren.

Nö, das war ne schnelle Testphase, die Klasse sieht mitlerweile komplett anderster aus. Generell was in meinem Block steht kam aus einer Experimentellen Phase, dessen Code, ich später angepasst hatte.

 

[maki]

Auch wenn ich bei der verwendung von RuntimeExceptions falsch gelegen habe, mag ich sie trotzdem nicht in einer API haben, ich weis worum es geht und der rest war nicht aus den fingern gezogen. Letztendlich steht doch noch die nette Argumentliste von SlaterB im Raum zum Thema Sicherheitsrisko bei unchecked Exceptions, was hier warum auch immer total von euch ignoriert wurde ;-)

Solltest die Liste von SlaterB nochmals lesen, da steht auch was von Nachteilen drinnen
Mit SlaterB zu diskutieren ist nicht dasselbe wie mit dir zu diskutieren, sorry, aber imho fehlt dir da einfach zuviel Hintergrundwissen.

Wie dem auch sei, wir sind hier im Anfängerforum, wenn da einer fragt zu "checked vs. unchecked Exceptions", dann sollte da nicht genau das Gegenteil von dem drinnstehen was Realität ist, RTEs "schlechten Programmierstil" zu nennen ist genau das, zu behaupten dass RTEs nur von der JVM geworfen werden sollten auch, was du "magst" oder nicht ist egal, aber wir sind hier nicht bei "Tomate_Salats Welt".

 

[SlaterB]

Checked Exceptions sind im kleinen Rahmen super, die Probleme wird man erst in großen Projekten kennenlernen,

wenn bestimmte APIs wie FileReader oder Hibernate bei Query-Ausführen derartige Exceptions werfen (würden, Hibernate ja nicht mehr), habe ich persönlich damit auch kein Problem, denn ein solcher Aufruf würde eh nur genau einmal im Programm stehen und sowieso von try/ catch umgeben sein, allein schon fürs Logging,

richtig Probleme machen die Checked Exception aber z.B. bei RMI mit der RemoteException,
da kann man die Aufrufe nicht irgendwo konzentrieren sondern sollten quasi unsichtbar ganz normalen Code abbilden

a.y();
b.y(); // b ist ein entfernes Objekt, Remote-Zugriff
c.y();

leider müsste man dann

a.y();
try {
b.y(); // b ist ein entfernes Objekt, Remote-Zugriff
catch {..
c.y();

schreiben oder diverse eigentlich für sich fertige Methoden unverständlich mit einer fremden Signuatur 'throws RemoteException' versehen,
das kann nicht gewünscht sein, hier helfen unsichtbare RuntimeExceptions, die nur an ganz wenigen zentralen Controller-Stellen behandelt werden

(eine Erklärung ohne jede Überheblichkeit oder Beleidigung)

 

[Tomate_Salat]

Solltest die Liste von SlaterB nochmals lesen, da steht auch was von Nachteilen drinnen

ich rede ja auch nicht davon, dass checked Exceptions nur vorteile haben, hab ich nie behauptet. Aber es steht ein riesngroßer Nachteil der unchecked Exceptions drin. Das immernoch konsequent von euch ignoriert wird.

RTEs "schlechten Programmierstil" zu nennen ist genau das, zu behaupten dass RTEs nur von der JVM geworfen werden sollten auch

war ein blödes missverständnis meinerseits und habe ich auch eingeräumt und auch geschrieben: das Argument kann nicht so zählen und wird von mir zurückgenommen.

was du "magst" oder nicht ist egal, aber wir sind hier nicht bei "Tomate_Salats Welt".

sagt ja keiner.

Edit Ich klinke mich hier aus, habe das Gefühl, diese Diskussion könnte sonst noch hässlich werden und zum Schluss nimmt man sich hier, sowohl wie in anderen Themen nicht mehr wirklich ernst, fände ich schade, da ich von dem Forum und dessen Member hier sehr viel halte ;-). Meine Meinung werde ich beibehalten, allerdings werde ich mir RuntimeExceptions näher anschauen, da mein Bild von denen ja offensichtlich nicht der realität entsprach.

 

[Atze]

finde slater hat es vor allem mit dem letzten post am genauesten getroffen, ohne dass ich hier jetzt partei ergreifen will. vielleicht sollten wir es damit belassen, bevor hier noch einer amok läuft muss halt jeder wissen, wie er seine api am besten designed!

 

[bygones]

muss halt jeder wissen, wie er seine api am besten designed!

und genau das fuehrt dann zu den unbrauchbarsten und unsinnigsten APIs...

aber wie slater richtig sagte - während des "Cowboy hackings" was man während der schul und anfangs studentenzeit noch macht ist das nicht so tragisch. Spätestens im produktiveinsatz in Firmen sollte jeder Archtiket bzw QS ABteilung dann ein ernstes Wort mit euch reden ;-)

 

[Atze]

und genau das fuehrt dann zu den unbrauchbarsten und unsinnigsten APIs...

dann ist das ja eigene schuld, wenn die api nicht gern gesehen oder nicht benutzt wird. wenns "seine" (also ein privatprojekt) ist.
von firmen hab ich ja nicht geredet da muss man sich dann wohl an die internen strukturen halten.

 

[André Uhres]

Hier noch ein paar (hoffentlich nützliche) Anmerkungen zu Exceptions:

Einerseits sind Exceptions eine nützliche "Entwicklungshilfe". Der Compiler warnt uns, damit wir nicht drei Wochen später unser ganzes Programm zusammenflicken müssen.

Andererseits enthalten sie aber auch das potentielle Problem der "überflüssigen" Exceptions. Das sind solche, die höchstens grobe Programm- oder Konfigurationsfehler aufdecken oder eh nie auftreten. Eine gute Lösung ist, diese explizit zu filtern. Vorsicht: nicht maskieren oder ignorieren. Außer wenn es sich nur um eine einzelne Codezeile handelt und man sicher ist, dass es kein Fehler ist, dann kann man auch mal eine Exception ignorieren.

RuntimeExceptions verwenden wir oft, wenn es sich immer nur um einen Programmfehler handeln kann. Bei logischen Anwendungsfehlern sind aber Exceptions nützlich. Und wir filtern, wo es angebracht ist: throw new RuntimeException(ex).

Für die meisten Anwendungen genügt übrigens eine einzige AnwendungsException, mit Typkonstanten zur Unterscheidung der einzelnen Fälle.