Eure Wunschliste für Java 7?

[didjitalist]

Ich finde das Konzept der checked exceptions gut, nur ist die Umsetzung in den meisten Fällen schlecht. Warum z.B. schmeissen ausnahmslos alle Datenbank APIs checked exceptions, wenn irgendwas mit der Verbindung nicht stimmt? Solche exceptions treten im normalen Programmablauf so gut wie nie auf. Ausnahmen, die aller Wahrscheinlichkeit nach normalerweise nicht auftreten, sollten auch keine checked exceptions schmeissen.

Erst sobald eine Methode eine sehr hohe Wahrscheinlichkeit besitzt, eine exception zu schmeissen, sollte dies eine checked exception sein. Als Beispiel können da Methoden wie Integer#parseInt herhalten.

 

[AlArenal]

@didjitalist:

Ich glaube dir ist die (gar nichtmal so tiefe) Bedeutung des Wortes "Ausnahme" entgangen...

 

[didjitalist]

Es geht hier nicht um die Begrifflichkeit "Ausnahme". Es geht um die Unterscheidung zwischen checked und unchecked exceptions.

Ich sehe wenig Sinn im inflationären Gebrauch von checked exceptions. Das verleitet lediglich dazu, genau die exceptions, die fatal sein können, geflissentlich zu ignorieren. Warum denn setzt sogar eine recht gebräuchliche IDE wie eclipse als Standardpattern für automatisch generierten Code das unglaublich sinnfreie "e.printStackTrace()" ein? Ich hab schon verdammt viel Code gesehen, der checked exceptions immer weiter und weiterreicht, bis sie irgendwann irgendwo im GUI verschluckt werden, weil irgendwer "mal eben" was umsetzen und sich zu dem Zeitpunkt keine Gedanken über sinnvolle Fehlerbehandlung mehr machen wollte.

 

[AlArenal]

Gegen verhunzten Code helfen keine Featuritis, denn schlechten Stil kann man nicht "Par Ordre De Mufti" unterbinden. Vorhandene Möglichkeiten sinnvoll einzusetzen ist numal Aufgabe des Programmierers und der kann sich nciht darauf berufen, dass ihn die Sprache verleitet hätte, obwohl er es auch hätte besser machen können.

Nachträglich Features entfernen ist erfahrungsgemäß nichts, was man von Sun zu erwarten hat.

 

[byte]

Das Konzept ist imo ok, aber es fehlt eine Möglichkeit, ohne Code Bloat alle checked Exceptions zu fangen.

 

[SlaterB]

> Warum denn setzt sogar eine recht gebräuchliche IDE wie eclipse als Standardpattern für automatisch generierten Code das unglaublich sinnfreie "e.printStackTrace()" ein?

auch hier wieder mahnende Gegenworte:
was anderes geht gar nicht, das ist schon eine sehr löbliche Sache,

wenn man von Eclipse Operationen mit Rückgaberwer generieren lässt,
dann wird da 'return null' reingeschrieben,
auch wenig sinnvoll aber Eclipse kann sich nun wirklich keinen intelligenten Code ausdenken

wenn Eclipse standarmäßig
throw new RuntimeException(e);
schreiben würde, ja dann wäre die Einstellung der Eclipseprogrammierer deutlich :bae:

 

[tfa]

Das Konzept ist imo ok

Wenn es nichtmal die Java-Schöpfer vernünftig verwenden (siehe viele checked Exceptions bei Reflection, SQLException), was kann man von normalen Entwicklern erwarten?
Checked Exceptions könnten vielleicht bei der Anwendungsentwicklung sinnvoll sein (wenn man wirklich weiß, dass eine Ausnahmesituation behandelt werden kann und muss), aber nicht in allgemein verwendbaren APIs oder Frameworks.

 

[SlaterB]

andererseits erziehen Checked Exceptions zur Kapselung,

ich finde es immer ganz schrecklich, wenn Framework-Operationen im Programm verteilt sind,
z.B. Hibernate query.list() oder transaction.commit(),

da das ein Einzeiler ist, steht das in meinem Projekt bei jeder von hunderten DB-Operationen einzeln,
und wenn ich nun die Querys zählen, loggen, gar auf Exceptions reagieren will?

wäre diese wichtige Operation ein 10 Zeilen-Code mit try/ catch,
dann wäre sie hoffentlich schon viel eher in eine Wrapper-Operation gewandert die von hunderten Stellen im Programm aufgerufen wird,

das ist kein direkter Zusammenhang mit Checked Exceptions, schließlich gibts auch genug Operationen ganz ohne Exceptions, die man evtl. wrappen möchte,

aber wenn eine Operation eines Framework Exceptions wirft,
dann braucht man die in einem strukturierten Programm nur genau einmal abzufangen,
dieser Aufwand ist nicht allzu hoch

 

[byte]

Das hat nun aber wirklich nichts mit dem Exception-Konzept zu tun sondern vielmehr mehr mit dem Design Deiner Anwendung. Oben aufgezählte Hibernate-Methoden werfen alle eine HibernateException, aber die ist halt Unchecked. Die kannst Du genauso fangen wie eine checked Exception, musst es aber nicht.
Du musst hier überlegen, wie Du Deine Persistenzschicht strukturierst - ob checked oder unchecked Exceptions fliegen ist dabei doch egal.

Warum sollte man ein try { query.list } catch(Exception e) { /* Exception Handling */ } eher wegkapseln? Jemand, der weiss was er tut, wird sich eh eine Persistenzschicht mit DAOs hochziehen. Und wer nicht weiss was er tut, der wird auch hier nichts vernünftig kapseln.

 

[SlaterB]

> Warum sollte man ein try { query.list } catch(Exception e) { /* Exception Handling */ } eher wegkapseln?

aufgrund der Code-Länge, wie gesagt,
wenn du das nicht so siehst ist das ja ok, aber brauchst nicht nochmal warum fragen

 

[byte]

Aha, na dann. :roll:

 

[Generic1]

Ich hab jetzt auch einen Wunsch,
Das Drucken in Java sollte so schnell als möglich überarbeitet werden, da keine Modifikationen an den PrintFrames (Seite einrichten und drucken) möglich sind, das aber manchmal sinn macht,

lg

 

[AlArenal]

http://www.softframeworks.com/products/products.php

 

[DEvent]

> Warum sollte man ein try { query.list } catch(Exception e) { /* Exception Handling */ } eher wegkapseln?

aufgrund der Code-Länge, wie gesagt,
wenn du das nicht so siehst ist das ja ok, aber brauchst nicht nochmal warum fragen

Ich wuerde eher sagen wegen vermeidung von Code-Duplication. Im uebrigem neigen checked-Exceptions sowieso zu code-duplication.

Was spricht eigentlich fuer checked-Exceptions? Doch nur das man sie fangen muss. Aber was der Programmierer damit macht, steht nirgens. Wenn Eclipse nicht immer ein // TODO hinzufuegen wuerde, dann wuerden die gefangenen checked Exceptions noch schneller in Vergessenheit geraten.

Frueher habe ich mir keine Gedanken gemacht um checked/unchecked Excepions, aber je laenger ich darueber nachdenke desto mehr komme ich zu dem Schluss, dass sie eine ganz schlechte Idee sind. In der Theorie hoert sich das ganz gut an: Wie zwingen die Programmierer mit checked Exceptions zur richtiger Fehler-Behandlung. In der Praxis zeigt sich aber die wahre Natur eines jeden Programmierer: Die Faulheit.

Ohne checked Exceptions ist die Faulheit kein Problem: Wenn der Programmierer zu faul zur richtigen Fehler-Behandlung war, dann beendet sich das Programm wenn eine Exception fliegt. Mit checked Exeptions laeuft das Programm weiter in einem undefinierten Zustand.

 

[SlaterB]

> Ich wuerde eher sagen wegen vermeidung von Code-Duplication. Im uebrigem neigen checked-Exceptions sowieso zu code-duplication.

klar Code-Duplication, wenns nicht der gleiche Code wäre, dann könnte man ihn ja nicht in eine Operation zusammenfassen,
Code-Duplication == Code-Länge

-----

ein guter Vergleich zwischen Checked und Unchecked ist auch ein Interface vs Adapter/ Basisklasse,
bei ersterem fängt man ganz bei null an und muss alles behandeln,
bei zweiterem verläßt man sich auf den Default, muss eigentlich nix machen sondern überschreibt nur (fängt nur ab), was aktuell nötig ist

das passt auch zum Kapselungs-Konzept,
wenns keinen WindowAdapter gäbe, dann müsste man ihn sich wirklich selber schreiben bei derart vielen Operationen die man oft nicht braucht