cosmochaosmaker hat gesagt.:
Du weisst das ich ne NULL in Java bin.

Kannst Du mir das Erklären?
Was würde das für einen Nutzen bringen?
Checked Exception zwingen den Benutzer einer Biblothek sich darum zu kümmern
wie er mit Ausnahmen umgeht.
Beispiel ein Datenbank Klasse, welche natürlich SQLException werfen kann, wenn z.b
der SQL Server nicht erreichbar ist.
Definiere ich das diese Methode eine SQLException wirft dann muss sich jeder der meine
Klasse nutzt Gedanken machen wie er mit diesem Umstand umgeht.
Bei einer Datenbank Klasse ist es zwar vom Namen her ersichtlich das hier Datenbank Operationen durchgeführt werden.
Deshalb nehmen wir mal ein etwas abstrakeres Beispiel.
Eine Klasse eines CMS das einen Links herausgibt.
Innerhalb dieser Klasse wird auch rekursiev ein Verzeichniss durchsucht um vorhandene Dateien zu behandeln.
Das hier eine Fileoperation durchgeführt wird ist durch die Klassenbezeichnung MenuOut nicht erkennbar. Die Methode getMenus() aber wirft eine IOException, weshalb der Programmierer gezwungen wird daran zu denken das hier Dinge schief gehen können.
Habe ich eine Methode die eine bestimmte Exception zwar werfen könnte aber dies meist recht unwahrscheinlich ist und nur in Ausnahmefälle auftritt dann leite ich meine Exception von RuntimeException ab, und sie kann auch abgefangen werden, muss es aber nicht.
Sprich es ist eine Designentscheidung, um was für eine Exception es sich handelt, und wie und ob sie behandelt werden muss.
cosmochaosmaker hat gesagt.:
Würde es nicht weitere Exceptions mit sich nachziehen?
Nein wieso sollte es?
Du muss keine Exception weiter nach oben reichen. Du kannst genau das selbe wie mit einer unchecked Exception machen (wie Java-RuntimeException oder eben C#) sie ignorieren.
Nur musst du dies bei checked Exception explizit machen.
try { Menu[] menus = MenuOut.getMenues() } catch(IOException e) { // mir egal }