# Sinn von RuntimeExceptions?



## hdi (18. Feb 2010)

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


----------



## rambozola (18. Feb 2010)

hdi hat gesagt.:


> Dabei musste ich feststellen dass mir die RuntimeExceptions (also unchecked) selbst ein Rätsel sind.



Hm tatsächlich? Ich hab nie verstanden wozu checked Exceptions gut sein sollen, die gehören nämlich abgeschafft!


----------



## hdi (18. Feb 2010)

Aha, also gegensätzliche Meinung, interessant. Wieso findest du sie gehören abgeschafft? Ich persönlich sehe darin schon Sinn: Wenn in meinem Code etwas schief gehen kann und es kann von Anwendung zu Anwendung unterschiedlich sein, wie man darauf reagieren soll, habe ich durch checked Exceptions die Möglichkeit, in meiner API zu sagen: Pass auf was du tust, x und y kann hier in die Hose gehen, überleg dir was du in so einem Fall machst!

Ich sehe in den unchecked keinen Sinn, weil sie nicht auf sich aufmerksam machen und nix weiter darstellen als eine Meldung in der Konsole (mit anschliessendem Thread-Kill).

Die Diskussion ist eröffnet


----------



## tfa (18. Feb 2010)

Ich finde auch, dass checked Exceptions mehr Nachteile als Vorteile mit sich bringen.
Ein bisschen was dazu habe ich hier zusammengeschrieben: http://www.java-forum.org/blogs/tfa/79-exceptions-faq.html


----------



## miwoe (18. Feb 2010)

Hum, ich seh das anders.

(Fast) Jeder Fehler ist behebbar. Nur ist es manchmal sehr aufwändig zu programmieren Ganz besonders:



> Was soll aber passieren, wenn IOException in einem Server-Prozess fliegt, etwa, weil die Konfigurationsdatei
> der Servers nicht gelesen werden kann oder kein freier Festplattenspeicher mehr verfügbar ist. Diese
> Situationen sind nicht behebbar. Es bleibt einem nichts anderes übrig, als die Exception zu loggen, ggf. den
> Administrator zu verständigen und das Programm zu beenden.



Warum soll das weniger behebbar sein? Man muss dem Server "nur" mit der Richtlinie ausrüsten, die auch der menschliche Benutzer verwenden würde, wie z.B. eine Default-Konfiguration wählen, Festplattenspeicher frei machen, etc. In Hochverfügbarkeitsumgebungen kann ich dir garantieren, dass dieser Fehler behandelt werden wird.

Finde ich sehr schlechtes Beispiel oder schlechte Argumentation. Wenn du sagen willst, dass die Exception ohnehin nur beim Serverstart geworfen wird, bei dem folglich dann die Entwickler den Fehler behandeln sollen und nicht der aktive Thread, dann geb ich dir recht. Wenn jedoch die Konfiguration regelmäßig neu eingelesen wird, wird sie garantiert behandelt.

Andererseits stimme ich zu, dass ein Compiler dennoch kompilieren können sollte, wenn eine Check Exception nicht abgefangen wird. Wenn der Entwickler nicht will, dann will er eben nicht. Entwicklungsumgebungen sollten dann lediglich dazu raten, eine Behandlung zu schreiben.

Nervig ist halt nur sowas:


```
try {
...
catch (Exception e) {
  // Todo: Auto-generated catch clause
}
```


----------



## musiKk (18. Feb 2010)

hdi hat gesagt.:


> 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.



Ganz kurz: Weil man auch nicht darauf reagieren soll; unchecked Exceptions sollen Programmierfehler darstellen. IOException kann man nicht beeinflussen, aber bei einer NPE fehlt halt schlicht und ergreifend der null-Check, etc.

So wars jedenfalls geplant (oder zumindest interpretiert). Wie die anderen schreiben geht die Entwicklung eher weg von den checked Exceptions.


----------



## Marco13 (18. Feb 2010)

Ist vielleicht ein bißchen... "flach", das Besipiel, aber ... sowas wie eine NullPointerException kann ja schlecht checked sein.... !? Und die können ja praktisch _überall_ auftreten... Ich finde auch, dass Checked Exceptions manchmal "nervig" sein können. Wer schonmal mit RMI zu tun hatte, oder versucht hat, mit Reflection eine Methode aufzurufen, und sich dabei mit... 5 oder 6 Checked Exceptions für einen Aufruf rumschlagen durfte, weiß, was ich meine. Aber sie gleich ganz abschaffen...? Hm. Eine definitive Meinung habe ich nicht. Es gibt wohl kein silver bullet.

(Geek And Poke: Simply Explained: Checked Exceptions  )


----------



## The_S (19. Feb 2010)

Ui ... das Lieblingsthema, das grundsätzlich für ein paar feuchte Augen hier im Forum sorgt  . 

@hdi einfach mal im Forum danach suchen. Müsste schon unzählige Threads zu dem Thema geben, in denen alle Vor- und Nachteile der jeweiligen Exceptions bis ins Detail geklärt wurden.


----------



## tfa (19. Feb 2010)

miwoe hat gesagt.:


> Hum, ich seh das anders.
> Warum soll das weniger behebbar sein? Man muss dem Server "nur" mit der Richtlinie ausrüsten, die auch der menschliche Benutzer verwenden würde, wie z.B. eine Default-Konfiguration wählen, Festplattenspeicher frei machen, etc. In Hochverfügbarkeitsumgebungen kann ich dir garantieren, dass dieser Fehler behandelt werden wird.


Nach meiner Definition ist die Serverkonfiguration zwingend nötig, um den Server überhaupt erstmal zu starten. Keine Konfiguration->Fataler Fehler. Warum sollte man den Fehler verstecken, indem man aufwendig eine Krücke drum rum programmiert? Ebenso die volle Festplatte. Soll das Programm zufällig irgendwelche Dateien löschen?


> Finde ich sehr schlechtes Beispiel oder schlechte Argumentation. Wenn du sagen willst, dass die Exception ohnehin nur beim Serverstart geworfen wird, bei dem folglich dann die Entwickler den Fehler behandeln sollen und nicht der aktive Thread, dann geb ich dir recht.


So meinte ich das.



> Wenn jedoch die Konfiguration regelmäßig neu eingelesen wird, wird sie garantiert behandelt.


Behandelt wird natürlich jeder Fehler. Aber dazu braucht man keine checked Exceptions. RuntimeExceptions kann man genauso fangen und behandeln.


> Andererseits stimme ich zu, dass ein Compiler dennoch kompilieren können sollte, wenn eine Check Exception nicht abgefangen wird. Wenn der Entwickler nicht will, dann will er eben nicht. Entwicklungsumgebungen sollten dann lediglich dazu raten, eine Behandlung zu schreiben.


Dann wären es keine checked Exceptions mehr. Genau das wäre wünschenwert (obwohl es nie passieren wird).
Fakt ist nunmal, dass andere Sprachen dieses Konzept bewusst nicht umsetzen und sogar viele bekannte Java-Frameworks nur noch RuntimeExceptions verwenden.


----------



## Tomate_Salat (19. Feb 2010)

ich MAG checked Exceptions. Solange sie bedacht und sinnvoll geworfen werden. Ich mags nur nicht, wenn eine Klasse diese bereits im Konstruktor wirft :-!. Ich halte Sie aber dennoch für sinnvoll, da dem Benutzer der Klasse gleich mitgeteilt wird, an welchen Stellen probleme auftauchen können. Trotzdem sollte man mit diesen Sparsam umgehen. UncheckedExceptions mag ich nicht wirklich und dass Programmierer selbst RuntimeExceptions schmeisen finde ich ehrlich gesagt ne katastrophe! 

Wenn ich in meinem Code eine Exception einbaue dann hat das schon seine Gründe: a) Die komponente ist nur unter Gewissen Bedinungen verwendbar und b) ich informiere von vorne rein, dass man den Code nur bestimmt anwenden kann und dass es zu fehler x oder y führen kann, wenn man nicht ordnungsgemäß mit umgeht!


----------



## maki (19. Feb 2010)

Checked Exceptions sind eine Krankheit die abgeschafft gehört 



> UncheckedExceptions mag ich nicht wirklich und dass Programmierer selbst RuntimeExceptions schmeisen finde ich ehrlich gesagt ne katastrophe!


Katastrophe?
Nein, sondern ein Mittel um mit der Krankheit checked Exceptions klarzukommen.

Die Diskussion checked vs unchecked Exceptions ist schon lange geführt worden, mit dem Egebniss, dass checked Exceptions vermieden werden sollten.


----------



## Landei (19. Feb 2010)

Checked Exceptions sind krank, und das lässt sich ganz einfach begründen: Angenommen ich habe ein Interface für das Einlesen einer Konfiguration. Implementierungen dieses Interfaces können nun die Konfiguration aus einer Datei, einer Datenbank, einem Webservice oder sonstwo auslesen. In jedem Fall können andere checked Exceptions auftreten, ich habe aber keine andere Möglichkeit, sie ans Interface weiterzuleiten, als irgendeinen vorgegebenen Exception-Typ zu verwenden und die checked Exceptions hübsch zu verpacken, weil ich ja nicht voraussehen kann, welche checked Excpetions mir um die Ohren fliegen werden. Checked Exceptions zum Teil der Methoden-Signatur zu machen, ist einfach pervers. Die einzige Möglichkeit, die ich sehe, um das zu fixen, wäre einer Erweiterung von Generics, so dass ich schreiben könnte:

```
interface ConfigReader<Ex extends Exception> {
   public Config read(String identifier) throws Ex;
}

class FileConfigReader implements ConfigReader<FileNotFoundException> {
   public Config read(String identifier) throws FileNotFoundException {
      //do the magic
   }
}
```


----------



## Noctarius (19. Feb 2010)

Die Generics Erweiterung klingt gut, aber zu deinem "Nachteil":
Ich will einen Parser bauen, so dafür nehm ich eine ParserFailedException. Jetzt könnte die Datei, welche ich parsen will, nicht existieren. Ergo würde eine IOException fliegen.

Die Frage ist in diesem Fall was ich haben will:
1. Ich will einfach nur eine Exception die ich dem User zeigen kann oder
2. Mich interessiert nur indirekt was wirklich passiert ist (als Coder z.B.) aber dem User will ich sagen, dass der Parser nicht arbeiten konnte oder
3. Ich will einfach nur dafür sorgen, dass wenn der Parser nicht kann (immer wenn eine ParserFailedException kommt) soll er was anderes versuchen.

Ich könnte alle 3 Fälle auch über [c]throws Exception[/c] abfangen aber ob das schöner ist. Auch an diesem Punkt würde die Generics-Erweiterung nicht viel nützen, weil [c]Ex extends Exception[/c] genau das selbe Problem machen würde wie Runtime Exceptions. Ich wüsste nicht was ich abfangen muss. Es kann schließlich nahezu alles (außer Error und Throwable) fliegen.


----------



## byte (19. Feb 2010)

miwoe hat gesagt.:


> Warum soll das weniger behebbar sein?



Es geht nicht darum, ob etwas behebbar (checked) oder unbehebbar (unchecked) ist. Es geht darum, dass es meistens am sinnvollsten ist, Exceptions nur an einer oder wenigen Stellen zu behandeln (nämlich in einem Exception Handler). Und dafür sind Checked Exceptions eben nicht geeignet, denn die MUSS man sofort behandeln. Unchecked Exceptions hingegen müssen nicht behandelt werden, sondern fliegen automatisch weiter und werden spätestens vom Uncaught Exception Handler des Threads behandelt.


----------



## byte (19. Feb 2010)

musiKk hat gesagt.:


> Ganz kurz: Weil man auch nicht darauf reagieren soll; unchecked Exceptions sollen Programmierfehler darstellen. IOException kann man nicht beeinflussen, aber bei einer NPE fehlt halt schlicht und ergreifend der null-Check, etc.



Warum sollte man nicht auf unchecked Exceptions reagieren? Man kann sie genauso behandeln wie checked Exceptions. Man muss es aber nicht. Das ist der einzige Unterschied.

Ich fange sehr häufig RuntimeExceptions und behandele sie.


----------



## byte (19. Feb 2010)

Tomate_Salat hat gesagt.:


> Wenn ich in meinem Code eine Exception einbaue dann hat das schon seine Gründe: a) Die komponente ist nur unter Gewissen Bedinungen verwendbar und b) ich informiere von vorne rein, dass man den Code nur bestimmt anwenden kann und dass es zu fehler x oder y führen kann, wenn man nicht ordnungsgemäß mit umgeht!



Und wozu brauchst Du dafür Checked Exceptions? Was ist, wenn der Entwickler genau weiss, wie Dein Code zu verwenden ist. Dann muss er trotzdem die Checked Exceptions behandeln, obwohl sie faktisch nie auftritt -> Boilerplate Code!


----------



## Landei (19. Feb 2010)

Um mein Beispiel um die Benutzer-Seite zu erweitern und ein bisschen neue Syntax zu erspinnen:


```
class Client {
...
  Config config = null;
  try<Ex extends Exception> {
     ConfigReader<Ex> configReader = ConfigReaderFactory.getConfigReader(); 
     config = configReader.read();
  } catch (Ex ex) {
      ExceptionHandler<Ex> exceptionHandler = ExceptionTools.findHandler(ex);
      if(exceptionHandler != null) {
          exceptionHandler.handle(ex); 
      } else {
         ex.printStackTrace();
         System.exit(0x29A); 
      }
  }
  ...
```

Aber das zeigt schon, dass es schwierig würde, damit vernünftig umzugehen...


----------



## Noctarius (19. Feb 2010)

Dann kann ich aber auch gleich Exception ansich abfangen und an einen entsprechenden ExceptionHandler weiterreichen, mach ich Heute an manchen Punkten schon so.


----------



## byte (19. Feb 2010)

Landei hat gesagt.:


> ```
> interface ConfigReader<Ex extends Exception> {
> public Config read(String identifier) throws Ex;
> }
> ...



Das sehe ich jetzt aber nicht wirklich als Problem von Checked Exceptions. Man kann sich ja problemlos für so eine Config Reader API eine ConfigReaderException als Basis-Exception definieren und dort dann alle möglichen (implementierungsspezifischen) Exceptions wrappen.

Oder gibt es ein ungeschriebenes Gesetz, dass sobald eine Datei nicht gefunden wurde, umbedingt immer eine FileNotFoundException fliegen muss?  Hier könnte man einfach eine ConfigReaderException definieren und davon eine ConfigNotFoundException ableiten. Diese könnte ja problemlos eine mögliche FileNotFoundException wrappen.

Wer mal eine schöne Exception Hierarchie sehen will, der gucke sich org.springframework.dao.DataAccessException + Ableitungen an. Natürlich alles Unchecked Exceptions.


----------



## Tomate_Salat (19. Feb 2010)

byte hat gesagt.:


> Und wozu brauchst Du dafür Checked Exceptions? Was ist, wenn der Entwickler genau weiss, wie Dein Code zu verwenden ist. Dann muss er trotzdem die Checked Exceptions behandeln, obwohl sie faktisch nie auftritt -> Boilerplate Code!



Und was ist wenn nicht?! Checked Exceptions haben den Vorteil, dass man einfach auf Sie reagieren kann. Ich verwende z.B. eine eigens entwickelte Console für mein aktuelles Projekt. Wenn jz soetwas auftritt wie: "Server-url" falsch, dann kann ich schon an der Exception die evtl. geschmissen wird sehen, wo das Problem mal entstehen kann. Ich brauche mir keine ellen-lange Exception ausgeben lassen, wo im prinzip drinn steht: "Url nicht korrekt". Da kann ich eleganter drauf reagieren und mir in die Console schreiben lassen: URL nicht gefunden und dann einen export der Konsoleneinträge machen lassen. Unchecked Exceptions kommen i.d.R. eher unerwartet und werden (noch) nicht von meiner Console abgefangen + registriert.
Checked Exceptions sind mir da schon lieber, auch wenn der try-catch-block einem auf die nerven gehen kann.


----------



## maki (19. Feb 2010)

> Und was ist wenn nicht?! Checked Exceptions haben den Vorteil, dass man einfach auf Sie reagieren kann.


Checked Exceptions haben den Nachteil, dass man auf sie reagieren _muss_, egal ob man sie sinnvoll behandeln kann oder nicht..

Dann führen sie noch zu "leaky abstractions", zu überflüssigem Code (try/catch ohne Grund bzw. Sinn), alles in allem sind sie eine schlechte Sache, ist aber alles schon x-mal gesagt worden, keien andere Sprache hat den Fehler der checked Exceptions nachgemacht, aus gutem Grund.

Der einzige mögliche Vorteil von checked Exceptions ist eben, dass der Entwickler vergessen könnte seine Exceptions in die JavaDoc zu schreiben mit unchecked Exceptions, dafür versaut man sich aber das Interface (leaky abstraction).


----------



## byte (19. Feb 2010)

Tomate_Salat hat gesagt.:


> Und was ist wenn nicht?! Checked Exceptions haben den Vorteil, dass man einfach auf Sie reagieren kann....



Du kannst genauso einfach auf Unchecked Exceptions reagieren wie auf Checked Exceptions. Du musst einfach nur in die Javadoc gucken, was unter @throws aufgeführt ist. In einer sauberen Javadoc sind dort Unchecked Exceptions genauso beschreiben wie Checked Exceptions.

Oder dachtest Du, man muss solange warten, bis sie das erste Mal fliegen, um auf Unchecked Exceptions zu reagieren?


----------



## tfa (19. Feb 2010)

Tomate_Salat hat gesagt.:


> Checked Exceptions haben den Vorteil, dass man einfach auf Sie reagieren kann.


Checked Exceptions haben den Nachteil, dass man einfach auf Sie reagieren _muss_. 

Auch wenn man sie nicht behandeln kann. Die Entwickler des API, das checked Exceptions vorschreibt, kann gar nicht wissen, ob sein Client (also du) die Ausnahme behandeln kann. Also sollte er es auch nicht vorschreiben.

Ich behaupte, 95% aller gängigen Exception aus der Standard-API lassen sicht nicht an Ort und Stelle beheben. Alles was mit SQLException, RemoteException, alle Exceptions, die mit Reflection zu tun haben, und auch viele IOExceptions. Alle mit try-catch oder throws abhandeln zu müssen ist nutzlos und fehleranfällig.



> Ich verwende z.B. eine eigens entwickelte Console für mein aktuelles Projekt. Wenn jz soetwas auftritt wie: "Server-url" falsch, dann kann ich schon an der Exception die evtl. geschmissen wird sehen, wo das Problem mal entstehen kann. Ich brauche mir keine ellen-lange Exception ausgeben lassen, wo im prinzip drinn steht: "Url nicht korrekt". Da kann ich eleganter drauf reagieren und mir in die Console schreiben lassen: URL nicht gefunden und dann einen export der Konsoleneinträge machen lassen. Unchecked Exceptions kommen i.d.R. eher unerwartet und werden (noch) nicht von meiner Console abgefangen + registriert.



Wenn du in deinem geschlossenen Programm eine eigene checked Exception definierst, über die du volle Kontrolle hast, mag das OK für dich sein. Dieser kleine Vorteil kann aber den grundsätzlichen Nachteil nicht aufheben.



> Checked Exceptions sind mir da schon lieber, auch wenn der try-catch-block einem auf die nerven gehen kann.


try-catch kannst du auch um RuntimeExceptions machen, wenn es nötig ist. Man muss seinen Code sowieso bezüglich Fehlerhandlung testen, am besten durch Unit-Tests. Der Behandlungszwang von checked Exceptions gaukelt einem nur Sicherheit vor.


----------



## Landei (19. Feb 2010)

byte hat gesagt.:


> Das sehe ich jetzt aber nicht wirklich als Problem von Checked Exceptions. Man kann sich ja problemlos für so eine Config Reader API eine ConfigReaderException als Basis-Exception definieren und dort dann alle möglichen (implementierungsspezifischen) Exceptions wrappen.
> 
> Oder gibt es ein ungeschriebenes Gesetz, dass sobald eine Datei nicht gefunden wurde, umbedingt immer eine FileNotFoundException fliegen muss?  Hier könnte man einfach eine ConfigReaderException definieren und davon eine ConfigNotFoundException ableiten. Diese könnte ja problemlos eine mögliche FileNotFoundException wrappen.



Sag ich ja: Da sowas nicht geht, muss man wrappen. Wrapped man, muss man im Nachhinein rausfinden, was drinsteckt. Hat man eine "normale" Exception, kann man über verschiedene catch-Blöcke den richtigen Typ herausfiltern. Hat man eine gewrappte Exception, geht das nicht mehr. Damit ist der ganze Sinn von checked Exceptions meiner Meinung nach für'n Dutt. Hinzu kommt, dass ja mit einmaligen Wrappen nicht Schluss ist: Ich habe öfter mit Sachen zu tun wie einer RuntimeException, in der eine RemoteException steckt, in der eine CheckInException steckt, in der eine BusinessObjectNotFoundException steckt, in der eine NullPointerException steckt. Was soll der Blödsinn?


----------



## Tomate_Salat (19. Feb 2010)

byte hat gesagt.:


> Du kannst genauso einfach auf Unchecked Exceptions reagieren wie auf Checked Exceptions. Du musst einfach nur in die Javadoc gucken, was unter @throws aufgeführt ist. In einer sauberen Javadoc sind dort Unchecked Exceptions genauso beschreiben wie Checked Exceptions.
> 
> Oder dachtest Du, man muss solange warten, bis sie das erste Mal fliegen, um auf Unchecked Exceptions zu reagieren?



Für Java-Doc alles nachzuschaun bin ich zu faul :rtfm::autsch:, dann lieber en try-catch-block mehr. 

Nö mir ist schon klar, dass man auf die reagieren kann, auch wenn sie noch nicht geschmissen wurden. Aber es ist leichter sie zu übersehen!



tfa hat gesagt.:


> Checked Exceptions haben den Nachteil, dass man einfach auf Sie reagieren _muss_.
> 
> Auch wenn man sie nicht behandeln kann. Die Entwickler des API, das checked Exceptions vorschreibt, kann gar nicht wissen, ob sein Client (also du) die Ausnahme behandeln kann. Also sollte er es auch nicht vorschreiben.



Ist wohl besser, wenn sie ihm einfach das Programm killen ;-)



> Ich behaupte, 95% aller gängigen Exception aus der Standard-API lassen sicht nicht an Ort und Stelle beheben. Alles was mit SQLException, RemoteException, alle Exceptions, die mit Reflection zu tun haben, und auch viele IOExceptions. Alle mit try-catch oder throws abhandeln zu müssen ist nutzlos und fehleranfällig.



Wenn der SQL falsch ist... Auch wenn man sie nicht sofort beheben kann, muss man sie beheben. Ich finde nachwievor es nicht verkehrt, den Entwickler auf kritische Stellen hinzuweisen. Wenn man z.B. einen falschen SQL sendet, dann kann das a) am Programm oder b) am Benutzer liegen. Ist B) der fall, dann muss das ganze nicht dokumentiert werden und geht den Entwickler letztendlich nichts mehr an und der Benutzer kann darauf hingewiesen werden. Im falle a, solltle das Dokumentiert und gesendet werden. Klar sollte man Eingaben immer Kontrollieren, aber einen SQL auf seine komplette richtigkeit prüfen?! Da ist ein try-catch wohl wesentl. kürzer.



> try-catch kannst du auch um RuntimeExceptions machen, wenn es nötig ist. Man muss seinen Code sowieso bezüglich Fehlerhandlung testen, am besten durch Unit-Tests. Der Behandlungszwang von checked Exceptions gaukelt einem nur Sicherheit vor.



Sind wir einer Meinung, aber auch hier musst du try-catch einsetzen um auf die RuntimeExceptions zu reagieren. Wer noch nie etwas von RuntimeExceptions gehört hat, dem gaukeln Sie bestimmt Sicherheit vor, allerdings helfen Sie auf kritische und anfällige Stellen zu reagieren. 

Eine Möglichkeit einzubauen, solche Exceptions nicht zu behandeln halte ich für viel gefährlicher. Vor allem Anfänger werden sich wohl dann noch kaum um diese kümmern und sagen: verwerfen wir sie einfach mal. Manche Exceptions mögen sinnlos sein, weil sie z.B. auf den späteren Programmverlauf vllt wirklich kaum bis gar keine auswirkung haben. Aber das ist meiner Meinung nach die Minderheit. 

Mögliches Fehlverhalten gehört einfach behandelt, auch wenn man das Problem vllt nicht lösen kann, kann man das Programm dennoch in eine andere Richtung lenken. Alles andere ist für mich einfach schlechter Programmierstil


----------



## bygones (19. Feb 2010)

Tomate_Salat hat gesagt.:


> Für Java-Doc alles nachzuschaun bin ich zu faul :rtfm::autsch:, dann lieber en try-catch-block mehr.


schlechter programmierstil erlaubt keine unsinnigen sachen... das Problem ist wenn du zu faul bist etwas zu tun und eine API bereitstellst die andere nutzen wollen / muessen, sind sie auf die Dinger die deiner Faulheit zu Grunde liegen angewiesen... und das ist mehr als unschoenes (nett formuliert) programmieren.

ansonsten stimme ich den meisten hier zu: checked exceptions sind ne krankheit.



Tomate_Salat hat gesagt.:


> Mögliches Fehlverhalten gehört einfach behandelt, auch wenn man das Problem vllt nicht lösen kann, kann man das Programm dennoch in eine andere Richtung lenken. Alles andere ist für mich einfach schlechter Programmierstil


und was hat das mit (un)checked Exceptions zu tun ? Natuerlich gehoeren Fehlerfaelle behandelt, natuerlich gehoeren sie geloest wenn moeglich... dafuer aber checked Exceptions einzusetzen ist nun mal ein ziemlich falscher weg


----------



## tfa (19. Feb 2010)

@Tomate_Salat

Ich glaube wir haben hier ein grundlegendes Missverständnis. Natürlich werden Exceptions nicht einfach _verschluckt_, sondern irgendwann behandelt (ich hätte _beheben _statt _behandeln _schreiben sollen). Aber bitte  an einer zentralen Stelle in einem ExceptionHandler, der Fehler loggt oder anzeigt und das Programm ggf. in einen Fail-Safe-Zustand bringt. Und nicht an 1000 Stellen über den Code verstreut, wie das bei checked Exceptions nötig wäre.
Für eine angemessene Behandlung reichen aber immer RuntimeExceptions aus. Eine angemessene Behebung ist selten möglich - meine Erfahrung.



> Klar sollte man Eingaben immer Kontrollieren, aber einen SQL auf seine komplette richtigkeit prüfen?! Da ist ein try-catch wohl wesentl. kürzer.


Hm, also meine Anwender geben keine SQL-Query ein. SQLExceptions gibt es eher, wenn keine DB-Connection zu stande kommt, oder ein Timeout fliegt oder irgendeine View nicht vorhanden ist usw.



> Eine Möglichkeit einzubauen, solche Exceptions nicht zu behandeln halte ich für viel gefährlicher. Vor allem Anfänger werden sich wohl dann noch kaum um diese kümmern und sagen: verwerfen wir sie einfach mal.



Gerade das passiert doch bei checked Exceptions, die Anfänger einfach verschlucken, weil sie gezwungen werden, sie zu fangen! RuntimeExceptions werden nicht verworfen, wenn man sie nicht fängt. Sie fliegen bis ganz nach oben und landen im ExceptionHandler.


----------



## Tomate_Salat (19. Feb 2010)

bygones hat gesagt.:


> schlechter programmierstil erlaubt keine unsinnigen sachen... das Problem ist wenn du zu faul bist etwas zu tun und eine API bereitstellst die andere nutzen wollen / muessen, sind sie auf die Dinger die deiner Faulheit zu Grunde liegen angewiesen... und das ist mehr als unschoenes (nett formuliert) programmieren.


Sehe ich nicht als schlechten Programmierstil. Wenn etwas unklar ist, schau ich natürlich in die Doc. Ich sehe das ganz anderster: Wenn der Entwickler RuntimeExceptions für sein vorhaben missbraucht, dann werden mir die in der Entwicklerumgebung "verheimlicht". Ist dazu die Api evtl. dazu nicht richtig Dokumentiert, habe ich als Entwickler nochmal ein Problem mehr! Das setzt also vorraus das ich eine gescheite Dokumentation habe. Wenn ich sicher gehen will, müsste ich (falls möglich!) noch den anderen code durchgehen?! 



> RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine.



Dabei sollte es bleiben, alles andere ist in meinen Augen schlechter Programmierstil. Wenn man diese zweckenfremdet, dann sollte man einen guten Grund haben. Ansonsten sollten normale Exceptions her



> und was hat das mit (un)checked Exceptions zu tun ? Natuerlich gehoeren Fehlerfaelle behandelt, natuerlich gehoeren sie geloest wenn moeglich... dafuer aber checked Exceptions einzusetzen ist nun mal ein ziemlich falscher weg



Nein gerade nicht, du musst eben auf checked Exceptions reagieren und das solltest du nutzen um Fehlverhalten auszuschließen


----------



## bygones (19. Feb 2010)

Java ist (afaik) die einzige moderne OOP sprache die auf das konstrukt von checked exceptions setzt... C++ oder c# kennen diese schon gar nicht. Moderne weiterentwicklungen fuer die VM auch nicht (Groovy Scala etc)...

es gibt schon ein Grund warum andere sich davor druecken.

Best Practices for Exception Handling - O'Reilly Media beschreibt es recht nett.

Deine Annahme dass die Nutzung einer RuntimeException Verfremdung sei ist leider einfach falsch.

Des weiteren SOLLTE man Unittests haben die Fehlerfaelle abdecken und das richtige Behandeln sicherstellen... alles ueber checked exceptions sicherstellen zu wollen ist falsch


----------



## maki (19. Feb 2010)

> Dabei sollte es bleiben, alles andere ist in meinen Augen schlechter Programmierstil.


Mit verlaub, ich erlaube mir zu behaupten dass du einfach noch nicht genug mit (checked) Exceptions gearbeitet hast, was du als "schlechten Programmierstil" siehst ist die "best practice" wenn es um Exceptions geht, findet man in der Literatur & Praxis.

Schon mal korrekten JDBC Code geschrieben?
try/catch Blöcke innerhalb von try/catch Blöcken, aber natürlich ohne die Möglichekit sinnvoll damit umzugehen, denn wenn der Server bzw. das Netzwerk weg ist, gibt es nix was man machen/programmieren kann, was macht man also? Genau, schlucken von Exceptions.....


----------



## tfa (19. Feb 2010)

Ich kenne checked Exceptions auch nur in Java. 
In Groovy (Java-kompatibel) hat man sie wieder ausgebaut.
In C# (eigentlich ziemlich Feature-geil) hat man sie nicht übernommen.
In Hibernate hat man sie anfangs verwendet, aber vor ca. 5 Jahren ausnahmslos durch RuntimeExceptions ersetzt.
Das Spring-Framework benutzt ebenso keine checked Exceptions.
Hier noch ein Artikel von Bruce Eckel: Bruce Eckel's MindView, Inc: Does Java need Checked Exceptions?


----------



## Atze (19. Feb 2010)

bygones hat gesagt.:


> es gibt schon ein Grund warum andere sich davor druecken.



ja, weil sie vielleicht nicht richtig damit umzugehen wissen. wie in dem artikel beschrieben, sollte man sie halt direkt im auftretenden layer behandlen oder zumindest nicht unmittelbar/unverarbeitet weiterpropagieren, damit die oberen layer nicht unhandlebare exceptions reingeworfen bekommen. dann ist doch alles gut  bin froh, dass es in java die checked gibt, und der compiler einem über die schulter schaut


----------



## musiKk (19. Feb 2010)

byte hat gesagt.:


> Warum sollte man nicht auf unchecked Exceptions reagieren? Man kann sie genauso behandeln wie checked Exceptions. Man muss es aber nicht. Das ist der einzige Unterschied.



Ich sage nur, dass das die Intention war oder ich zumindest derartige Interpretationen las (also checked - fangen/weiterwerfen, unchecked - nicht fangen, da Programmierfehler).
Das war nur zur Beantwortung einer der Kernfragen aus dem ersten Post und sollte auch völlig wertungsfrei gewesen sein; die Diskussion hat ja schon einen Bart und macht mir persönlich überhaupt keinen Spaß (mehr).


----------



## maki (19. Feb 2010)

> ja, weil sie vielleicht nicht richtig damit umzugehen wissen.


Nö, sondern weil checked Exceptions ein Designfehler sind, von Grund auf.



> damit die oberen layer nicht unhandlebare exceptions reingeworfen bekommen


Was heisst den "unhandlebare Exceptions"?
RuntimeExceptions können exakt so behandelt werden wie checked Exceptions, nur ohne die ganzen Nachteile.


----------



## Atze (19. Feb 2010)

maki hat gesagt.:


> Was heisst den "unhandlebare Exceptions"?
> RuntimeExceptions können exakt so behandelt werden wie checked Exceptions, nur ohne die ganzen Nachteile.



um das beispiel aus dem artikel zu nehmen:
wenn exceptions aus der model-ebene (datenbank) sinnlos als bspw. SQLExceptions in die geschäftslogik geschmissen werden.


----------



## maki (19. Feb 2010)

> um das beispiel aus dem artikel zu nehmen:
> wenn exceptions aus der model-ebene (datenbank) sinnlos als bspw. SQLExceptions in die geschäftslogik geschmissen werden.


SQLExceptions sind doch checked Exceptions, also musst du diese sowieso fangen und übersetzen (exception translation), ausser du willst die Geschäftslogik von SQLExceptions abhängig machen. :autsch:
Dasselbe macht man mit RuntimeExceptions.. nur sauberer 
Nebenbei, das ist nicht die Model-Ebene, sondern die Persistenz-/Integrationsebene.


----------



## Atze (19. Feb 2010)

maki hat gesagt.:


> SQLExceptions sind doch checked Exceptions, also musst du diese sowieso fangen und übersetzen (exception translation), ausser du willst die Geschäftslogik von SQLExceptions abhängig machen. :autsch:
> Nebenbei, das ist nicht die Model-Ebene, sondern die Persistenz-/Integrationsebene.



ja, davon red ich doch!  ich glaub wir reden in die gleiche richtung, aber an einander vorbei  die businesslogik soll da ja nichts (unbrauchbares) von mitbekommen. sie sqlEx sollte man dann ja nicht als checked weiterreichen, weil sie ja dann dort unsinnigerweise behandelt werden müsste. also muss sie ja dann behandelt oder übersetzt werden. und wie wir die ebene nennen, ist ja nur nebensache, oder?  sorry, wenns falsch rüberkam! freundschaft!?!


----------



## maki (19. Feb 2010)

Atze hat gesagt.:


> ja, davon red ich doch!  ich glaub wir reden in die gleiche richtung, aber an einander vorbei  die businesslogik soll da ja nichts (unbrauchbares) von mitbekommen. sie sqlEx sollte man dann ja nicht als checked weiterreichen, weil sie ja dann dort unsinnigerweise behandelt werden müsste. also muss sie ja dann behandelt oder übersetzt werden. und wie wir die ebene nennen, ist ja nur nebensache, oder?  sorry, wenns falsch rüberkam! freundschaft!?!


Freundschaft sowieso... 
In einem Schichtenmodell dürfen sowieso bestimmte Exceptions an die nächste "höhere" Schicht weitergegeben werden, da kommt man um ein [c]catch (Exception e) ...[/c] nicht herum.

Ob ich drunter checked oder unchecked Exceptions verwende ist da egal(ausser für den Code und das Design), aber wenn ich zB. in der Persistenz Schicht Hibernate einsetze, will ich ja nicht HibernateExceptions bis in die GUI bekannt machen müssen.


----------



## Atze (19. Feb 2010)

mein ich ja


----------



## Tomate_Salat (19. Feb 2010)

maki hat gesagt.:


> Mit verlaub, ich erlaube mir zu behaupten dass du einfach noch nicht genug mit (checked) Exceptions gearbeitet hast, was du als "schlechten Programmierstil" siehst ist die "best practice" wenn es um Exceptions geht, findet man in der Literatur & Praxis.


Ich habe genug mit Exceptions gearbeitet ;-)



> was macht man also? Genau, schlucken von Exceptions.....



Wenn es nicht immer sein muss, exceptions zu behandeln, sehe ich kein Problem diese zu schlucken. Trotzdem sehe ich nach wie vor nichts verkehrtes daran, dem Entwickler anfälliges mitzuteilen, was letztendlich hilft Fehler zu vermeiden.


----------



## bygones (19. Feb 2010)

Tomate_Salat hat gesagt.:


> Ich habe genug mit Exceptions gearbeitet ;-)


aus unserer sicht nicht ;-) v.a. wenn dich solche konstruktor wie erwaehnt try/catch in try/catch bloecken nicht stoeren...




Tomate_Salat hat gesagt.:


> Wenn es nicht immer sein muss, exceptions zu behandeln, sehe ich kein Problem diese zu schlucken.


ich denke es ist beiden klar dass "exceptions schlucken" gefahrenpotential hoch tausend hat... und sonst ist es genau ein punkt der diskussion. Durch checked exception wirst du gezwungen sie zu schlucken, auch wenn du nix damit anfangen kannst. 



Tomate_Salat hat gesagt.:


> Trotzdem sehe ich nach wie vor nichts verkehrtes daran, dem Entwickler anfälliges mitzuteilen, was letztendlich hilft Fehler zu vermeiden.


richtig und das geschieht ueber die API bzw deren Dokumentation. Wer sich daran halten will kann dies tun, wer nicht muss mit moeglichen konsequenzen rechnen. Allen anderen aber etwas aufzuzwingen ist einfach unsinn.

bygones - diskussion tret sich dann irgendwann im kreis


----------



## maki (19. Feb 2010)

> Ich habe genug mit Exceptions gearbeitet


Sorry, aber das glaube ich niemandem der checked Exceptions gut findet 



> Wenn es nicht immer sein muss, exceptions zu behandeln, sehe ich kein Problem diese zu schlucken.


So, du findest also überflüssige try Blöcke und leere catch Blöcke gut?
Vielleicht haben wir nur andere Definition von "gut" & "schlecht", zumindest würde es erklären warum du die Best Practice beim Umgang mit Exceptions als "schlechter Programmierstil" siehst.



> . Trotzdem sehe ich nach wie vor nichts verkehrtes daran, dem Entwickler anfälliges mitzuteilen, was letztendlich hilft Fehler zu vermeiden.


Dafür gibt es doch JavaDoc, man muss doch keine Designfehler (=checked Exceptions) dafür verwenden.


----------



## Tomate_Salat (19. Feb 2010)

bygones hat gesagt.:


> aus unserer sicht nicht ;-)



^^ ist mir klar


> v.a. wenn dich solche konstruktor wie erwaehnt try/catch in try/catch bloecken nicht stoeren...



Wenn sie sinnvoll sind nicht.



> ich denke es ist beiden klar dass "exceptions schlucken" gefahrenpotential hoch tausend hat...



steht wohl außer Diskussion

und sonst ist es genau ein punkt der diskussion. Durch checked exception wirst du gezwungen sie zu schlucken, auch wenn du nix damit anfangen kannst. 



> richtig und das geschieht ueber die API bzw deren Dokumentation. Wer sich daran halten will kann dies tun, wer nicht muss mit moeglichen konsequenzen rechnen.



Setzt eine gepflegte Dokumentation vorraus...und die ist nunmal nicht immer garantiert. Ist diese unsauber oder man hats einfach mal "vergessen" oder sonst was, dann hat man ungewohlt unbehandelte Exceptions! Das kann dir bei checked nicht passieren. 



> Allen anderen aber etwas aufzuzwingen ist einfach unsinn.


wir dürften uns doch einig sein, dass Exceptions behandelt werden sollten. Warum also das leben schwer machen und sagen: "schau in die api, auf was du achten musst"?! Letztendl. sollteste du jeden fall abdecken, ergo deine try-catch bleiben im Code, ansonsten haste unbehandelte Exceptions! 



> bygones - diskussion tret sich dann irgendwann im kreis


Nenne es Meinungsaustausch, ich erwarte und glaube nicht, dass hier iEiner seine Meinung ändert.


----------



## Tomate_Salat (19. Feb 2010)

maki hat gesagt.:


> Sorry, aber das glaube ich niemandem der checked Exceptions gut findet



Ich kann nicht glauben dass du uncheckt exceptions gut findest ;-). Andere Entwickler andere Meinungen ;-)



> So, du findest also überflüssige try Blöcke und leere catch Blöcke gut?



Nein, zumindest den den Stacktrace würde ich mir ausgeben lassen.



> Vielleicht haben wir nur andere Definition von "gut" & "schlecht", zumindest würde es erklären warum du die Best Practice beim Umgang mit Exceptions als "schlechter Programmierstil" siehst.



Nennen wirs: unterschiedliche Meinungen ;-). Meiner Meinung nach sollte, wie vorgesehen, nur die jvm RuntimeExceptions schmeisen.



> Dafür gibt es doch JavaDoc, man muss doch keine Designfehler (=checked Exceptions) dafür verwenden.



Ich verwende keine Designfehler ;-) ich verwende checked Exceptions


----------



## bygones (19. Feb 2010)

Tomate_Salat hat gesagt.:


> Setzt eine gepflegte Dokumentation vorraus...und die ist nunmal nicht immer garantiert. Ist diese unsauber oder man hats einfach mal "vergessen" oder sonst was, dann hat man ungewohlt unbehandelte Exceptions! Das kann dir bei checked nicht passieren.


du redest doch hier auch von gutem Programmierstil den du verlangst. Ergo gehoert eine API auch dokumentiert. 

dein Vorschlag klingt nach "Behandle eine simple Krankheit mit einer wesentlich schlimmeren, dann faellts jedenfalls auf".

falsches vorgehen - just as simple



Tomate_Salat hat gesagt.:


> Nein, zumindest den den Stacktrace würde ich mir ausgeben lassen.


autsch.... autsch... autsch....


----------



## tfa (19. Feb 2010)

Tomate_Salat hat gesagt.:


> Nenne es Meinungsaustausch, ich erwarte und glaube nicht, dass hier iEiner seine Meinung ändert.


Macht es dich nicht stutzig, dass du ziemlich alleine mit deiner Meinung da stehst? Ich meine nicht nur hier im Thread, sondern auch gegenüber all die genannten Fachartikel und Framework-/Programmiersprachen-Beispielen.


----------



## Tomate_Salat (19. Feb 2010)

bygones hat gesagt.:


> du redest doch hier auch von gutem Programmierstil den du verlangst. Ergo gehoert eine API auch dokumentiert.



Leider nicht immer garantiert



> dein Vorschlag klingt nach "Behandle eine simple Krankheit mit einer wesentlich schlimmeren, dann faellts jedenfalls auf".



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"


----------



## Tomate_Salat (19. Feb 2010)

tfa hat gesagt.:


> Macht es dich nicht stutzig, dass du ziemlich alleine mit deiner Meinung da stehst? Ich meine nicht nur hier im Thread, sondern auch gegenüber all die genannten Fachartikel und Framework-/Programmiersprachen-Beispielen.



Nein, ist meiner Meinung nach eh etwas Subjektives.



> Programmiersprachen-Beispielen.


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.


----------



## maki (19. Feb 2010)

> Ich kann nicht glauben dass du uncheckt exceptions gut findest . Andere Entwickler andere Meinungen


Kannst dich ja mal umsehen, du vertritst eine Einzelmeinung, die leider falsch ist.



> Nein, zumindest den den Stacktrace würde ich mir ausgeben lassen.


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?



> Nennen wirs: unterschiedliche Meinungen . Meiner Meinung nach sollte, wie vorgesehen, nur die jvm RuntimeExceptions schmeisen.


Wie kommst du den auf sowas???
Nochmals:


> RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine.


Da steht nirgendwo dass RTE nur von der JVM geschmissen werden sollen, dürfen oder dass es jemals so gemeint war.
Deine Behauptung dass RTEs so gemeint waren stammt vielleciht daher dass du den Text falsch verstanden hast, aber Fakten gibt es keine dafür.



> Ich verwende keine Designfehler


doch hier


> ich verwende checked Exceptions


----------



## tfa (19. Feb 2010)

Tomate_Salat hat gesagt.:


> Nein, ist meiner Meinung nach eh etwas Subjektives.



Die Meinungen zum GOTO-Statement oder zur Pointerarithmetik ist sicherlich auch was subjektives. Trotzdem gibt es einen weit verbreiteten Konsens.



> 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.


Das hat doch überhaupt nichts mit dem Thema zu tun.


----------



## hdi (18. Feb 2010)

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 (19. Feb 2010)

Tomate_Salat hat gesagt.:


> Leider nicht immer garantiert


sollte aber - ansonsten wird das stueck API nicht akzeptiert




Tomate_Salat hat gesagt.:


> 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 (19. Feb 2010)

maki hat gesagt.:


> 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. 



tfa hat gesagt.:


> Die Meinungen zum GOTO-Statement


Da teile ich durchaus die Meinung 



bygones hat gesagt.:


> 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 (19. Feb 2010)

Tomate_Salat hat gesagt.:


> 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 (19. Feb 2010)

Landei hat gesagt.:


> 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 (19. Feb 2010)

bygones hat gesagt.:


> 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.
> 
> ...


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 (19. Feb 2010)

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


----------



## Tomate_Salat (19. Feb 2010)

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 (19. Feb 2010)

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 (19. Feb 2010)

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 (19. Feb 2010)

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


----------



## SlaterB (19. Feb 2010)

byte hat gesagt.:


> 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 (19. Feb 2010)

@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 (19. Feb 2010)

byte hat gesagt.:


> 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)



byte hat gesagt.:


> @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 (19. Feb 2010)

SlaterB hat gesagt.:


> 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,
> ...



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 (19. Feb 2010)

byte hat gesagt.:


> 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 (19. Feb 2010)

Tomate_Salat hat gesagt.:


> 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 (19. Feb 2010)

Tomate_Salat hat gesagt.:


> 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 (19. Feb 2010)

Tomate_Salat hat gesagt.:


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



Weil es checked Exceptions gibt! ;(


----------



## byte (19. Feb 2010)

Tomate_Salat hat gesagt.:


> 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 (19. Feb 2010)

byte hat gesagt.:


> 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



byte hat gesagt.:


> 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 (19. Feb 2010)

tfa hat gesagt.:


> Weil es checked Exceptions gibt! ;(


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


----------



## maki (19. Feb 2010)

> 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 (19. Feb 2010)

Tomate_Salat hat gesagt.:


> 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 (19. Feb 2010)

byte hat gesagt.:


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



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:



tfa hat gesagt.:


> 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 (19. Feb 2010)

Tomate_Salat hat gesagt.:


> 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 (19. Feb 2010)

> 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 (19. Feb 2010)

byte hat gesagt.:


> 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.



maki hat gesagt.:


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


Bin ich anderer Meinung


----------



## byte (19. Feb 2010)

Tomate_Salat hat gesagt.:


> 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 (19. Feb 2010)

> 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 (19. Feb 2010)

maki hat gesagt.:


> 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 (19. Feb 2010)

Manche Leute machen Borniertheit zu einer Wissenschaft.


----------



## maki (19. Feb 2010)

Tomate_Salat hat gesagt.:


> 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
> ...


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 (19. Feb 2010)

maki hat gesagt.:


> 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)
> ...


----------



## Tomate_Salat (19. Feb 2010)

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 ;-)



byte hat gesagt.:


> @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 (19. Feb 2010)

Tomate_Salat hat gesagt.:


> 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 (19. Feb 2010)

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 (19. Feb 2010)

maki hat gesagt.:


> 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 (19. Feb 2010)

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 (20. Feb 2010)

Atze hat gesagt.:


> 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 (20. Feb 2010)

bygones hat gesagt.:


> 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 (24. Feb 2010)

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.


----------

