Zweifacher Try-Catch

[keksdose132]

Guten Morgen/Mittag/Abend,
ich möchte mal fragen, ob es möglich ist, dass bei einem Fehler in der Run Methode des Threads, die Exception des ersten Try-Catches aufrufen kann. So das statt "Exception1" im Log, "Exception2" ausgegeben wird.

try {
    Thread thread = new Thread(new Runnable() {
        @Override
        public void run() {
            try {   
                BufferedReader reader = new BufferedReader(new InputStreamReader(new URL("https://www.google.com").openStream()));
                reader.close();

                //Wenn hier ein Fehler auftritt -> Log.d("MyLog", "Exception2");
            }
            catch (Exception ex) { Log.d("MyLog", "Exception1"); }
        }
    });
    thread.start();
    thread.join();
}
catch (Exception ex) { Log.d("MyLog", "Exception2"); }

 

[VfL_Freak]

Moin,
wenn im inneren TRY eine Exception fliegt, dann wird sie auch dort gefangen!

Zudem fängt Du in beiden Fällen JEDE auftretende Exception (ex)! Das würde ich ggf. mal spezifisch einschränken!
So kann 'start' nur eine "IllegalThreadStateException" und 'join' nur eine "InterruptedException" auslösen!

Im inneren TRY können allerdings div. Exceptions auftreten!
Lass dir mal den gesamten Stacktrace ausgeben!

VG Klaus

 

[mrBrown]

Log einfach statt "Exception1" das gewünschte "Exception2"



Was willst du denn wirklich machen?

 

[mihe7]

@keksdose132 meine Glaskugel sagt mir, dass Du nicht weißt, wie Du außerhalb des Runnables an die Exception rankommen sollst, weil Du in Runnable die checked exception abfangen musst, richtig?

 

[kneitzel]

Also was ich mich frage: Wenn man den Thread direkt nach dem start joined: Dann kann man doch auf den Thread auch verzichten oder übersehe ich jetzt einen Grund, der für den Thread spricht.

Das Konzept ist etwas seltsam: Wenn ich einen separaten Thread habe, dann interessiert mich da ja in der Regel ein Ergebnis. Dieses Ergebnis kann dann vielseitig sein - angefangen von den gewünschten Daten bis halt hin zu einem "Daten konnten nicht ermittelt werden."
Das ist aber doch ein ganz generelles Prinzip. Und diesbezüglich gibt es dann auch extrem viel und oft sogar spezielle Klassen wie z.B. den SwingWorker bei Nutzung von Swing.
Aber generell sind hier viele Dinge denkbar und möglich. Aber bei den meisten Frameworks ist dies ein Thema, das relativ groß und breit dokumentiert ist. Also z.B.
Android: https://developer.android.com/guide/background (Hier gibt es dann ganz viele unterschiedliche Möglichkeiten was alles möglich ist)
Swing: https://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html
JavaFX: https://docs.oracle.com/javafx/2/threads/jfxpub-threads.htm
...

Also das Problem, das ich sehe:
Wenn Du einen separaten Thread startest, dann ist ja Dein Ziel, dass Dein Code weiter laufen kann. Das bedeutet, dass so ein try Block verlassen wird und dann der andere Thread sonst wo sein kann oder sogar schon beendet sein könnte -> Die Anforderung selbst ist relativer Unsinn in meinen Augen. Daher ist die Frage tatsächlich wichtig: Was willst Du wirklich machen? Die Wahrscheinlichkeit eines xy Problems scheint mir hier relativ hoch zu sein ...

 

[mrBrown]

Also was ich mich frage: Wenn man den Thread direkt nach dem start joined: Dann kann man doch auf den Thread auch verzichten oder übersehe ich jetzt einen Grund, der für den Thread spricht.

Könnte Android sein, da sind Netzwerkzugriffe ja nicht im Main-Thread erlaubt. (Allerdings ist das dann schon die dümmste "Lösung" dafür)

 

[kneitzel]

Ja, an Android habe ich auch etwas gedacht, denn dieses Log(TAG, message...) kenne ich eigentlich nur von Android. Und bei Android würde dann der DownloadManager oder WorkManager Sinn machen. Und selbst wenn nicht: Das .join() sollte auf jeden Fall weg, denn das blockiert die App dann ja wieder was ja explizit verhindert werden sollte.

Jedem, der Android Apps entwickeln will, empfehle ich, sich genau die Dokumentation durchzulesen. Diese Abkürzungen a.la. "Ich suche immer etwas im Netz und kopiere mir so lange Code zusammen bis irgendwas habe, das aussieht als würde es funktionieren" sind hier extrem schlecht, denn eine Android App hat von sich aus eine gewisse Komplexität und die sollte man auf jeden Fall verstanden haben. ==> https://developer.android.com/guide
Besonders wichtig wäre aus meiner Sicht Activities: https://developer.android.com/guide/components/activities/intro-activities?hl=en
Danach dann je nach Bedarf:
- Security: https://developer.android.com/topic/security?hl=en
- Intents: https://developer.android.com/guide/components/intents-filters?hl=en
- Testing: https://developer.android.com/training/testing/fundamentals?hl=en
- Resources: https://developer.android.com/guide/topics/resources/providing-resources?hl=en
...

Oder in Kurzform: Ohne ein Verständnis, was bei Android wie funktioniert ist es sehr wahrscheinlich, dass einem die App massiv auf die Füße fällt. Und im Endeffekt kostet es ein vielfaches an Zeit, als wenn man sich einmal den Überblick verschafft hat. Und wenn man den Überblick hat und die Begriffe kennt, dann kann man auch viel besser nach etwas suchen (und dann auch das finden, was man sucht...)