Arbeite seit langer Zeit mal wieder an einem Client mit GUI und in der Praxis sind unvorhergesehene Schicht-8 Fehler aufgetreten auf die ich keinen Einfluss habe.
Das Problem ist jetzt ich würde gerne eine Fehlermeldung anzeigen wenn eine Exception fliegt (die ich vorher nicht vorhergesehen habe).
Die stupideste Lösung wäre jetzt JEDE Methode mit “throws Exception” zu beschreiben und in der Main dann ein Fenster aufpoppen zu lassen.
Kennt ihr da eine elegantere Lösung?
Thread.setDefaultUncaughtExceptionHandler() 
Aber nicht vergessen, den aktuellen für Delegationszwecke (falls nötig) im eigenen zu speichern.
“throws Exception” wäre doch nur für Exceptions die man auch fangen muss, um die ist eh zu kümmern,
wenn im Moment in tiefen Ebenene viele try/ catch stehen, dann ist da sowieso Arbeit,
es klingt eher nach RuntimeExceptions, die unsichtbar nach oben durchkommen?
wenn wirklich alles in der Main-Methode landet, nur der Main-Thread, dann nur dort ein try/catch nötig, wohl nicht viel anders als setDefaultUncaughtExceptionHandler() hinsichlich Main-Thread,
mit GUI, (im Swing-Fall:) ActionListenern usw. gibt es aber eher für jede Aktion einen eigenen Thread?
dann etwas schwieriger, einen ExceptionHandler überall gesetzt zu haben,
aber ok, setDefaultUncaughtExceptionHandler() soll wohl extra für überall gelten
oder alternativ ein Aufbau, der jeden denkbaren Thread-Start in eine kontrollierte Umgebung mit gemeinsamer Basismethode für solche Aktionen bringt,
darin dann auch Dinge wie Log Start/ Ende, auch im Erfolgsfall ohne jede Exception, Log Parameter/ aufgerufenes Element, Zeitmessung, Nutzungshäufigkeitszählung, User-/ Ressourcen-Nutzungskontrolle, Bereitsstellung von Basisdaten, evtl. DB-Verbindung/ Transaktion und was immer allgemein anfallen könnte, Parallelisierungs-/ Wartefragen,
im Fehlerfall hätte dann man auch den kompletten Kontext für genauere Angaben statt nur Exception-Inhalt + maximal StackTrace zur Verfügung
zu ersetzen wären eine Handvoll Nahtstellen, wie als ActionListener statt Simpel-ActionListener eine Subklasse der eigenen Action-Klasse eben oder eine Hilfsmethode für addActionListener(), welche die Übernahme organisiert,
dazu ListSelectionListener usw., was alles anfällt, in großen Anwendungen paar mehr Hände voll,
falls nicht tiefer in Swing irgendwo alles von Swing auf einmal einzufangen, aber eigene Listener-Klassen/ Hilfsmethoden machen sich auch nicht schlecht, um etwa ActionEvent bei jedem ActionListener wegzuzaubern, mit Java 8-Abkürzung freilich nicht mehr so nervig wie früher,
genauso eigene gestartete Threads, statt simples Runnable die eigene Run-Klasse nutzen bzw. wieder eine Hilfsmethode die das normale Runnable nicht direkt an Thread übergibt, sondern eigenes zwischenschaltet
Danke, setDefaultUncaughtundsoweiter war die Lösung.
@SlaterB
Du hast Recht, den Unterschied zwischen Exception und Throwable hatte ich schon ganz vergessen. Dann wäre das auch mit der Main gegangen, aber wie du selber sagst gilt Spacerats Lösung überall.
Das mit den Threads ist zwar eine nette Idee, aber dann bräuchte ich einen weiteren Thread der nach dem Zustand der anderen Threads schaut und dann wäre die Frage, was tun wenn ein generischer Thread X mit einem Fehler abgebrochen hat.
Im Moment reiche ich alle mir bekannten Exceptions weiter nach oben bis ich zu einem Punkt komme an dem ich die nötige Entscheidungsgewalt habe eine Ausnahmehandlung zu bestimmen oder das Modul zu überspringen ohne einen invaliden State im Programm zu erreichen.
Aber manchmal fliegen halt irgendwo Runtime Exceptions weil das zu parsende Double ein Text ist, oder diese ganzen IOExceptions, oh Gott die IOExceptions 
Das einzige nervige sind Lambdas und ihre Unfähigkeit Exceptions weiter zu geben 
einen weiteren Thread braucht es an sich nicht,
wichtig ist eine gemeinsame Methode zu haben, die über alles wacht, wie die ja in ‚weiter nach oben bis ich zu einem Punkt komme an dem ich die nötige Entscheidungsgewalt habe‘ selber in etwa beschreibst,
die wichtige Methode in jedem Thread kann agieren, kein weiterer Thread dazu
Frage ist nur ob man kleine beliebige Threads zulässt, oder jeder Thread etwas kontrolliertes ist,
gar nicht so unendlich viel auch ActionListener-Aktionen usw. zu disziplinieren, gibt nur paar Grundtypen, aber eine Arbeit ist es freilich schon
jede IOException kann immer in eine RuntimeException gekapselt werden, auch nur eine Frage einer Reihe von Hilfsmethoden/ Wrapperklassen, im normaler Verwendung braucht nirgendwo IOException nahe bei Dateioperatoren usw. zu sehen sein