Eclipse RCP - Exceptions durchgeben

[Guest]

Hi,

ich hab nem größeren RCP - Projekt das Problem, dass einige Exceptions von Eclipse mehr oder weniger verschluckt werden.
So zum Beispiel beim Aufbau der Properties. Wenn dort Null-Pointer Exceptions auftreten, gibt Eclipse diese nicht weiter sondern sie werden irgendwo intern abgefangen und ich bekomm sie nicht zu Gesicht - einziges Indiz für solche Exceptions ist immer nur ein recht mysteriöses Verhalten meines Progs... :roll:

Wenn ich selbst ein try-catch Block um den Teil rumsetzt, in dem die Exception auftritt, kann ich diese abfangen.
So weit so gut - ist aber wie ich find recht unschön und auch ziemlich nervig, da oft nicht ganz klar ist, ob ein komisches Verhalten des Programms von der Programmlogik ausgeht, oder ob es irgendwo ne Exception gab, die Eclipse verschluckt hat von der man dann erstmal auch nicht genau weiß, wo diese aufgetreten sein könnte.

Mein Frage nun: Lässt sich Eclipse irgendwie dazu überreden, dass es diese Exceptions nicht intern ins Nirvana laufen lässt, sondern dass ich sie automatisch zu Gesicht bekomm...? :?:

Unschön wär ne Lösung, wo ich einfach alles in try-catch setzte - irgendwie ja nicht so Sinn der Sache... oder ???:L

 

[Wildcard]

Die gehen nicht ins Nirvana, sondern ins log (das du ebenfalls benutzen solltest).
GUI Code wird üblicherweise in SaveRunnables ausgeführt um den Event Thread zu schützen. Wenn du deine Exceptions nicht fängst, muss sich Eclipse eben darum kümmern. Beim Entwickekn immer die Error Log View öffnen, damit du sofort siehst wenn's knallt.

 

[Guest]

Danke schon mal für deine Hilfe.

Das ist ja eben gerade das große Problem, dass leider eben nicht alle Exceptions bis ins Log durchkommen... :roll:

Die ErrorLogView hab ich schon geöffnet, aber ich hab gerade nochmal die Exception konstruiert, die mir den letzten Nerv geraubt hat und die kam nicht bis ins ErrorLog durch... :bahnhof:

Beim Aufbau (Konstruktor) einer PropertySource greif ich auf ne Klasse zu, im die PropertyWerte zu füllen und ne Methode dieser KLasse greift auf en Variable zu, die NULL ist -> NullPointerException

Und diese seh ich eben leider nirgends in Eclipse - weder in der normalen Konsole noch im ErrorLogView...
Erst wenn ich n try-catch im Konstruktor der PropertySource rumsetzt, erhalte ich die NullPointerException

 

[Wildcard]

Ist schon möglich das an dieser Stelle keine Exception ins log kommt. Ist dann eher ein Bug und durchaus ungewöhnlich. Der Konstruktor einer PropertySource ist aber auch eine dämliche Stelle für eine NullPointerException (Konstruktoren allgemein).
Wenn du debuggst, an welcher Stelle bleibt die Exception hängen?

 

[Guest]

Gute Frage - kann ich so nicht sagen. Ich bekomm sie nur zu greifen, wenn ich selbst nen try-catch um den Aufruf rumsetzt, der die Exception wirft.

Aber wenn du ne Idee hast, wie ich das ganze noch anders lokaliesieren kann, bin ich für jede Hilfe dankbar. 🙂

 

[Wildcard]

Debugger verwenden. Dann siehst du schon was mit dem Ding passiert.

 

[Guest]

hm - wie kann ich mit dem Debugger Exceptions verfolgen, die mir (wenn ich selber keine try-catch Blöcke setzen) gar nicht angezeigt werden...?
Seh ich das dort irgendwo?

Mir scheint es auch so, als ob es ein Versionsspezifisches Problem von Eclipse ist.
Habs grad auf meinem Rechner mit Linux nochmal getestet und da kommt die Exception durch und wird mir angezeigt durch ein wunderschönes PopUp mit ner tollen NullPointerException ???:L
(Unter Windows konnte ich wie gesagt Eclipse erst mit einem try-catch block dazu überreden, mir diese anzuzeigen)
Wieder ein Grund mehr Windows nur unter Androhung von Strafe zu verwenden 😎

Nichts desto trotz muss es doch auch mit Eclipse Ganymede unter Windows möglich sein, diese Exceptions irgendwie zu Gesicht zu bekommen. Denn bei geschätzten 20.000 Zeilen Code ist die manuelle Lokalisierung doch recht nervenauftreibend...

 

[Wildcard]

Geh mit dem Debugger in die Zeile in der die Exception passiert, dann step forward und du bist im zuständigen Catch.
Du kannst auch Exception Breakpoints setzen wenn dir die Stelle nicht bekannt ist.

 

[Guest]

Danke Wildcard - man lernt doch nie aus :### das mit den exception Breakpoints hab ich nicht gewusst.

So wies aussieht, wird die Exception in diesem Fall von der RCP-Plattform in der Klasse org.eclipse.ui.internal.AbstractSelectionService abgefangen:

protected void fireSelection(final IWorkbenchPart part, final ISelection sel) {
        Object[] array = listeners.getListeners();
        for (int i = 0; i < array.length; i++) {
            final ISelectionListener l = (ISelectionListener) array[i];
            if ((part != null && sel != null)
                    || l instanceof INullSelectionListener) {
                
                try {
                    l.selectionChanged(part, sel);
                } catch (Exception e) {
                    WorkbenchPlugin.log(e);
                }
            }
        }
    }

An diesme catch bleibt sie hängen - so wies es aussieht liegt der Hund dann in der internen Implementierung von Eclipse begraben :autsch: Da ich unter der Linux-RCP-Version die Exception ja dann seh und sie unter Windows verschluckt wird.
Vielleicht mach ich mir mal die Mühe und Step durch die 50 Aufrufe durch, die die Exception dann durchläuft und schau mal nach, wo sie unter Windows dann genau weggeworfen wird. Scheint also wirklich ein kleiner aber feiner und nervenauftreibender Bug zu sein :roll:

Danke für deine Hilfe nochmal Wildcard

 

[Wildcard]

Danke Wildcard - man lernt doch nie aus das mit den exception Breakpoints hab ich nicht gewusst.

Es gibt auch noch conditional breakpoints :wink:
Rechtsklick auf einen Breakpoint -> Breakpoint Properties
Wird doch aber gelogget:
WorkbenchPlugin.log(e);

 

[Guest]

...
Wird doch aber gelogget:
WorkbenchPlugin.log(e);

ja schon - aber wie gesagt, seltsamerweise erscheint nichts im Logfile :roll:
Die Exception verirrt sich wohl irgendwie auf dem weg zum Logfile im Code-Dschungel...
Ich werd bei Gelegeheit mal komplett mit dem Debugger durchsteppen und schaun, an welchem Punkt dann die Exception-Msg genau verschwindet.