Execption auf Oberfläche werfen, try-catch-Block

[bastibe]

Sehr geehrte Forums-Mitglieder,
ich habe da ein Problem:
Und zwar wirft mir der folgende Quellcode eine NullPointer-Exception, unter einem bestimmten Testfall:
Grundsätzlich ist das Problem schon durch die Oberfläche behoben worden, würde es aber trotzdem gern lösen.
1. Ist der try-catch-Block so richtig aufgebaut?
2. Gibt es eine Möglichkeit die "catch" -Anweisung direkt in die Oberfläche zu überführen, da mir das System.out.... ja nur mit BlueJ o.ä. zur Verfügung steht, das Programm aber später selbstständig laufen soll!?

Vorschläge, Anregungen & Feedback wären sehr nett! 🙂

Liebe Grüße
bastibe

try{
if(auto.getmotor().equals(motoren[0]) && auto.getgetriebe().equals(getriebearten[1]))
{

System.out.println("!!!! Tip-Tronic nicht mit Standardmotor möglich !!!!");
auto.checkt(); /**setze variable check auf true*/
auto.setfehler(4); /**setze variable fehler auf "4"*/
auto.setnull(); /**setze alle attribute von auto mit der methode setnull auf "null"*/

}}
catch(NullPointerException e)
{System.out.println("Ein Autoelement ist noch nicht gewählt!"); }

 

[TheDarkRose]

Du könntest einen JDialog anzeigen lassen anstatt auf System.out zu schreiben

 

[Marco13]

NullPointerExceptions catcht man nicht. Stattdessen vorher auf 'null' testen.

 

[Gast2]

Hmmm, anstatt eine NPE zu fangen würde ich lieber versuchen die direkt zu vermeiden. Prinzipiell kann es ja in deinem Fall eigentlich nur [c]auto[/c] sein. Du könnest also einfach abfragen [c]if (auto == null) [/c] und dann ein Event zurück an die UI schießen, z.B. den User auffordern etwas zu ändern.

Meiner Meinung nach sollte es in 99% der Fälle möglich sein ohne [c]catch(NullPointerException npe)[/c] programmieren.

 

[GladstoneGander]

Prinzipiell kann es ja in deinem Fall eigentlich nur [c]auto[/c] sein.

Naja, getMotor() und getGetriebe() können ja auch null zurückliefern. Ebenso kann in den Methoden checkt(), setFehler() und setNull() natürlich auch eine NPE fliegen. Die wird ja durchgereicht.

Meiner Meinung nach sollte es in 99% der Fälle möglich sein ohne [c]catch(NullPointerException npe)[/c] programmieren.

Was wären denn 1% der Fälle, in denen es nicht möglich sei, ohne das catchen einer NPE zu programmieren?

 

[Gast2]

Naja, getMotor() und getGetriebe() können ja auch null zurückliefern. Ebenso kann in den Methoden checkt(), setFehler() und setNull() natürlich auch eine NPE fliegen. Die wird ja durchgereicht.

Ist richtig.

Was wären denn 1% der Fälle, in denen es nicht möglich sei, ohne das catchen einer NPE zu programmieren?

Wenn z.B. eine benutze lib mit NPEs um sich wirft. Ist aber wie gesagt sehr sehr selten und sollte eigentlich besser nie vorkommen. Habe ich allerdigns schon erlebt.

 

[bastibe]

Guten Morgen,

also der oben angezeigte Quellcode beschreibt einen Teil einer Restriktion für ein Autokonvigurator. Grundsätzlich ist eine "Null" belegung durch ein Dropdown/checkbox in der Oberfläche nicht möglich.
Theoretisch wäre es aber möglich wenn man es ohne Oberfläche nutzen würde, also dient mein Versuch eher dem Lerneffekt, als der Umsetzung des Projekts! 🙂 ich danke euch für eure Einträge.
Jetzt hab ich aber grad n Problem entdeckt und zwar geht mein Programm bei diesem Aufbau des try-catch-Blocks GARNICHT mehr. 🙂 soll heißen es führt die Überprüfung der Restriktionen nicht mehr durch.
Habs ausgetestet, das nicht funktionieren hängt mit den einfügn des Blocks zusammen.
Entdeckt da jemand einen Fehler?

Liebe Grüße