Exceptions

J

javastudent25

Bekanntes Mitglied
Hallo

Ich habe da einen Fehler, bei dem ich nicht weiss, wie ich diesen lösen kann.

Es handelt sich um:
No exception of type ArithmeticException can be thrown; an exception type must be a subclass of Throwable

Java: 
public class ArithmeticException {

    public static void main(String[] args) {
    
          new ArithmeticException();
          divide(2);

    }

    public static int divide(int a){
        int solution;
        try
        {
           solution = a/0;
        }
        catch (ArithmeticException e)
        {
            System.out.println("Division by null in not allowed");
        }
        return solution;
    }

}
 
Wie meinst du das? So etwa?
Das hatte ich versucht, das tut so auch leider nicht..

Java: 
public class ArithmeticException extends Exception{

    public static void main(String[] args) {
   
          new ArithmeticException();
          divide(2);

    }

    public static int divide(int a){
        int solution;
        try
        {
           solution = a/0;
        }
        catch (ArithmeticException e)
        {
            System.out.println("Division by null in not allowed");
        }
        return solution;
    }

}
 
Also ich habe das jetzt so gemacht und das funktioniert.
Aber ArithmeticException ist doch keine user defined exception.
Ich habe ja jetzt meine eigene Klasse einer Exception generiert.
Das muss doch ohne dem Extend ja auch irgendwie gehen, oder?

Übrigens kommt bei mir bei Division durch 0 infinity raus, also keine Standardfehlermeldung vom Compiler..

Java: 
public class ArithmeticException extends Exception {

    public static void main(String[] args) {

        divide(0);

    }

    public static double divide(int a) {
        double solution = 0;
        try {

            if (a <= 0) {
                throw new ArithmeticException();
            }
            solution = 1.0 / a;
            System.out.println(solution);

        } catch (ArithmeticException e) {
            System.out.println("Division by null in not allowed");
        }
        return solution;
    }

}

 
Ja, dein Code ist auch vollkommen falsch. Eine Exceptin steht alleine da und hat bestimmt keine main.

der Aufbau wäre quasi:

Code: 
class Calculator {
double divide(int a) throws ArithmeticException;
}

class ArithmeticException extends Exception {

}

und nein, ohne extends Exception oder extends Throwable geht das nicht. Dazu müsstest du dich mal in das Thema Exceptions einlesen.
 
ok, deine Variante versuche ich morgen.

Diese Variante funktioniert


Java: 
public class Arithmetic__exception1 {

    public static void main(String[] args) {
   
         
          divide(2);

    }

    public static int divide(int a){
        int solution=0;
        try
        {
           solution = a/0;
        }
        catch (ArithmeticException e)
        {
            System.out.println("Division by null is not allowed");
            System.out.println(e.toString());
        }
        return solution;
    }

}
 
Hey javastudent25,

darf ich fragen, was eigentlich das Problem ist? Hast du den Code im ersten Post geändert?
Der Code ist nämlich völlig in Ordnung. Du musst keine eigene Klasse definieren, um diese Exception schmeißen oder abfangen zu können...

Solltest du den Code verändert haben, wäre das für alle später dazukommenden Leser etwas unglücklich zu verfolgen.

Grüße
Coco07!
 
ok, was ist jetzt falsch was ist jetzt richtig?
Ich habe immer neue Codes gepostet, keine geändert.

übrigens habe ich nun eine etwas andere Variante und diese Variante, wenn ich es umkehrt mache, sprich a in den Nenner setze, kommt infinity dabei raus. Der Typ ist jetzt aber double, aber das sollte ja nichts zur Sache tun oder..

das war bei

publicclass Arithmetic__exception1 nicht so

Java: 
public class Arithmetic__exception2 {

    public static void main(String[] args) {
   
         
          divide(0);

    }

    public static double divide(int a){
        double solution=0;
        try
        {
           solution = 1.0/a;
           System.out.println(solution);
        }
        catch (ArithmeticException e)
        {
            System.out.println("Division by null is not allowed");
            System.out.println(e.toString());
        }
        return solution;
    }

}
 
Ehrlich gesagt ist das eine ziemlich knifflige Aufgabe, sogar für mich. Bei dem Datentyp "int" scheint es kein Problem zu sein, eine Division durch 0 zu catchen. Bei einem Wert vom Datentyp "double" scheint das Ganze etwas anders zu sein. Um mich jetzt in das Thema einzulesen fehlt mir einfach die Konzentration um diese Uhrzeit :/
Jedenfalls kannst du das Problem so lösen:
Java: 
public static double divide(double a){
            double solution = 0;
            try
            {
               solution = 1.0/a;
               if(Double.isInfinite(solution)){
                   solution = 0;
                   throw new ArithmeticException();
               }
            }
            catch (ArithmeticException e)
            {
                System.out.println("Division by zero in not allowed");
            }
            return solution;
        }

Wenn dich das Thema interessiert und dir die Lösung nicht reicht(so geht es mir meistens), dann kannst du dich hier einlesen:
klick mich!

Schöne Nacht noch 🙂

Grüße
Coco07!
 
javastudent25 hat gesagt.:
ok, deine Variante versuche ich morgen.

Diese Variante funktioniert
Zum Vergrößern anklicken....

Logisch funktioniert diese Variante, jetzt heisst deine Klasse aber auch nicht mehr ArithmeticException, das heisst du wirfst die "Standard-ArtithmeticException" von Java. Vorher wolltest du deine eigene Klasse als Exception werfen, deswegen auch meine Aussage das dies keinen Sinn macht.

Bei Double wird keine Exception geworfen, weil double NaN (bzw Infinty) darstellen kann, was int nicht kann => alles wird korrekt behandelt
 
das Problem ist, das bei einer Integer Division durch 0 eine ArithmeticException geworfen wird. Da du aber deine Klasse selber auch wieder ArithmeticException genannt hast, gibt es ein Problem bei catch(ArithmeticException).
Aufgrund der Sichtbarkeit wird hier halt davon ausgegangen, dass du deine eigene Klasse meinst, was eben nicht geht, da sie nicht von Exception erbt. Außerdem hätte es eh zu einem anderen Problem geführt, da die "echte" Arithmetic Exception nicht gefangen wird.
 
thecain hat gesagt.:
Logisch funktioniert diese Variante, jetzt heisst deine Klasse aber auch nicht mehr ArithmeticException, das heisst du wirfst die "Standard-ArtithmeticException" von Java. Vorher wolltest du deine eigene Klasse als Exception werfen, deswegen auch meine Aussage das dies keinen Sinn macht.

Bei Double wird keine Exception geworfen, weil double NaN (bzw Infinty) darstellen kann, was int nicht kann => alles wird korrekt behandelt
Zum Vergrößern anklicken....

du hast mir gerade 2 Fragen erspart.. 🙂
In diesem Fall wollte ich auch eine Standard-ArithmeticException machen.
Die muss ich ja nicht extra werfen lassen, wenn es Java ja sowieso tut.

InfectedBytes hat gesagt.:
das Problem ist, das bei einer Integer Division durch 0 eine ArithmeticException geworfen wird. Da du aber deine Klasse selber auch wieder ArithmeticException genannt hast, gibt es ein Problem bei catch(ArithmeticException).
Aufgrund der Sichtbarkeit wird hier halt davon ausgegangen, dass du deine eigene Klasse meinst, was eben nicht geht, da sie nicht von Exception erbt. Außerdem hätte es eh zu einem anderen Problem geführt, da die "echte" Arithmetic Exception nicht gefangen wird.
Zum Vergrößern anklicken....

Danke auch für die Erklärung mit der Sichtbarkeit. Das hat mir auch 1 Frage erspart.

Meine 2 Varianten Standard Exceptions sehen nun folgend aus:


Java: 
public class Arithmetic__exception1 {

    public static void main(String[] args) {

        divide(0);

    }

    public static int divide(int a) {
        int solution = 0;
        try {
            solution = 1 / a;
            System.out.println(solution);
        } catch (ArithmeticException e) {
            System.out.println("Division by null is not allowed");
            System.out.println(e.toString());
        }
        return solution;
    }

}
Java: 
public class Arithmetic__exception2 {

    public static void main(String[] args) {

        try {
            int b = divide(0);
            System.out.println(b);

        } catch (ArithmeticException e) {
            System.out.println("Division by null is not allowed");
            System.out.println(e.toString());
        }
    }

    public static int divide(int a) throws ArithmeticException {

        int solution = 1 / a;
        return solution;
    }
}
 
Ich habe ein weiteres Problem und zwar habe ich hier gelesen, dass ja eine NullPointerException dann geworfen wird, wenn eine Methode an einem Objekt aufgerufen wird, welches gar nicht vorhanden ist.
Demnach müsste dies ja gehen, wenn ich sage, andrew.speaks();
Tut aber nicht.


Java: 
public class Null_Pointer_Exception {

    public static void main(String[] args) {
       
        Person_NullPointer_Exception donaldTrump = new Person_NullPointer_Exception("Donald Trump");
       
        try {
           
             donaldTrump.speaks();
             andrew.speaks();

        } catch (NullPointerException e) {
            System.out.println("You ...: " + e.getMessage());
       
        }

    }

}
Java: 
public class Person_NullPointer_Exception{
   
    private String name;
   
    public Person_NullPointer_Exception(String name){
        this.name = name;
    }
   
    public void speaks(){
        System.out.println(name + " says: I know I speak first before i think");
    }
   
}
 
das kompiliert erst gar nicht, da andrew nicht deklariert wurde.
Die NullPointerException (NPE) wird geworfen, wenn die Variable null ist.
Java: 
Person p = null;
p.test(); // NPE
 
Das sind ja nur ganz einfache Beispiele um zu erläutern, wann eine NPE vorkommt. Code selbst ist ja viel komplizierter. Person p ist dann das Ergbnis eines Funktionsaufrufs. Und dann wird nicht auf null geprüft.

Wobei es für diese ganze Thematik schon Lösungsansätze gibt. Bei den NullPointerExceptions wäre dies z.B. die Einführung von Verträgen (Contracts), die vorgeben, ob null zurückgegeben werden darf oder nicht. Durch die Konsequente Nutzung solcher erweiterter Verträge kann der Compiler schon sicher stellen, dass es zu keinen NPEs kommen kann. Aber das ist noch Zukunftsmusik aber iContract und so gehen in diese Richtung.

Konrad
 
Das ist ja auch ein relativ simples Beispiel. Da kanns leicht klingeln. Bei komplexeren Abläufen klingelt es manchmal nicht so direkt und dafuer gibts diese Exception.
 
ok, ich habe noch eine Frage zur ClassNotFoundException
Wie funktioniert diese?
wenn ich nun das Programm fertig habe, und die Klasse Person_.... entferne, geht das ja nicht so einfach.
Weil ich es dann ja überhaupt nicht kompiliert bekomme..
 
Es könnte sein dass zur Laufzeit eine Klasse nicht gefunden wird die in deiner Entwicklungsumgebung aber sehr wohl vorhanden ist
 
Wenn während der Laufzeit eine Klasse nachgeladen wird.
Kann beispielsweise auftreten, wenn der JDBC-Treiber nicht geladen werden kann.
 
Also die ClassNotFound Exception kann auftreten, wenn Du z.B. Klassen beim kompilieren noch vorliegen hast aber bei der Ausführung diese nicht zur Verfügung stehen.

In Deinem Beispiel wäre das vergleichbar mit dem Löschen der Person.class Datei, die Du nach dem übersetzen bekommst. Aber in der Realität ist das oft ein Problem, dass eine Library nicht da ist.

Konrad
 
Ja das heisst aber, dass ich diese Exception eigentlich immer abfangen muss, weil das kann ja immer irgendwie sein, oder nicht?
Räumt mal einer irgendwelche Ordner auf und schiebt die Dateien hin und her, funktioniert das Ganze nicht mehr..
 
Musst du eigentlich nur abfangen wenn du sie selber behandeln willst. In der Regel ist bei dieser Exception aber kein sinnvoller Ablauf des Programmes möglich.
 
Ok, nach deiner Aussage, muss ich dann von den 8 versch. also 1, 3, 4, 5 abfangen..
Stimmt das?

1. Arithmetic
2. Class not found
3. IndexOutOfBound
4. InputMismatch
5. IOExceptiion
6. FileNotFound
7. NullPointer
8. IllegalArgument
 
Zuletzt bearbeitet:
Ich weiss ja nicht ob man das so allgemein formulieren kann aber das sind jedenfalls heisse Kandidaten. Allgemein würde ich sagen du fängst jede Exception ab bei der du weisst wie du sie in deinem Programm sinnvoll behandelst so dass das Programm weiterarbeiten kann.
 
Ergänzen würde ich noch, dass man immer überlegen sollte, in wie weit eine Exception nicht vermieden werden kann. IndexOurOfBound ist ein Kandidat, den ich nicht abfangen sondern vorab überprüfen würde, so dass dies nicht erst auftreten kann.
 
Es gibt sogenannte CheckedExceptions und UncheckedExceptions in Java. CheckedExceptions sind Exceptions, welche behandelt werden MÜSSEN. Ein gutes Beispiel dafür ist der Fall einer Dateianlegung auf der Festplatte, wo es z.B. zu Berechtigungproblemen kommen kann oder eine Datei im Falle von lesendem Zugriff gar nicht vorhanden ist. CheckedExceptions MÜSSEN behandelt oder an eine höher liegende Instanz "weitergereicht" werden. Du erkennst sie entweder daran, dass du einen Compilerfehler bekommst, sobald du sie ignorierst oder anhand ihrer Vererbungshierarchie. An den Stellen, an denen CheckedExceptions geworfen werden, können Programmierer bei richtiger Verwendung nichts dafür, dass es zu einem Problem gekommen ist und müssen deshalb für den Fall vorsorgen, dass etwas schief geht.
Eine UncheckedException ist in 99% aller Fälle ein Programmierfehler und kann durchaus mit Erfahrung vermieden werden(wenn man nicht gerade um 2 Uhr nachts im Schlaf programmiert...). Eine UncheckedException muss und sollte nicht behandelt werden, nur um Problemen aus dem Weg zu gehen, welche man aufgrund mangelnder Kenntnisse nicht lösen kann(dafür ist das Forum da 🙂). Ein gutes Beispiel für eine UncheckedException ist zum Beispiel eine NPE, welche durchaus über eine "if-Abfrage" oder im Falle einer Typüberprüfung auch durch den "instanceof-Operator" vermieden werden kann. Eine UncheckedException erbt von RuntimeException(du kannst auch eigene definieren...)

Ich hoffe, ich konnte dir einen etwas tieferen Einblick gewähren...

Grüße
Coco07!
 
Ich habe gerade diesbezüglich etwas gebastelt, bekomme es aber vorerst um weitere Fragen zu stellen nicht zum Laufen..
Was mache ich falsch?

bei
public class Slipsize_too_small_Exception throws SlipSizeTooSmallException{
zeigt es mir den Fehler:

Multiple markers at this line
- Syntax error on token "class", delete this token
- Syntax error, insert "enum Identifier" to complete
EnumHeaderName
- Breakpoint:Slipsize_too_small_Exception
- Syntax error, insert "EnumBody" to complete
CompilationUnit
- Syntax error, insert "}" to complete Block

Java: 
public class Slipsize_too_small_Exception throws SlipSizeTooSmallException{
   
   
    public void text (int slipSize){
       
        if (slipSize < 120 ){
            throw new SlipSizeTooSmallException();
            System.out.println("too small slipsize");
        }
        else{
            System.out.println("Successful, great Job");
        }   

    }

}



Java: 
public class SlipSizeTooSmallException extends Exception {

    public SlipSizeTooSmallException(){
       
        super("Slipsize of your girlfriend is greater than size you typed in");
    }
   
}



Java: 
public class Slipsize_too_small_Exception_Demo {

    public static void main(String[] args) {
       
        Slipsize_too_small_Exception exception = new Slipsize_too_small_Exception();
       
        exception.text(119);

    }

}

 
Kein Problem, wir sind da um zu helfen 🙂

Es ist eigentlich ganz einfach. Eine Klasse selbst kann keine Exception werfen, eine Methode schon. Schreibe die "throw-Klausel" hinter die Parameterliste deiner text-Methode.
Wenn diese Schreibweise nämlich funktioniert würde, könnte man ja 10 Methoden in einer Klasse definieren und alle dieser Methoden könnten eine Exception schmeißen. Der Aufrufer(in deinem Fall die main-Methode) darf dann jedes Mal einen try-catch Block um einen Methodenaufruf auf einer Instanz dieser Klasse schreiben, obwohl nur eine dieser 10 Methoden wirklich eine Exception schmeißen könnte.

Wenn du dieses änderst, wirst du bemerken, dass deine IDE beim Aufruf der text-Methode meckern wird, aber das lasse ich dich selbst lösen. Melde dich einfach, wenn du nicht weiterkommst 😉

Grüße
Coco07!
 
coco07 hat gesagt.:
Kein Problem, wir sind da um zu helfen 🙂

Es ist eigentlich ganz einfach. Eine Klasse selbst kann keine Exception werfen, eine Methode schon. Schreibe die "throw-Klausel" hinter die Parameterliste deiner text-Methode.
Wenn diese Schreibweise nämlich funktioniert würde, könnte man ja 10 Methoden in einer Klasse definieren und alle dieser Methoden könnten eine Exception schmeißen. Der Aufrufer(in deinem Fall die main-Methode) darf dann jedes Mal einen try-catch Block um einen Methodenaufruf auf einer Instanz dieser Klasse schreiben, obwohl nur eine dieser 10 Methoden wirklich eine Exception schmeißen könnte.

Wenn du dieses änderst, wirst du bemerken, dass deine IDE beim Aufruf der text-Methode meckern wird, aber das lasse ich dich selbst lösen. Melde dich einfach, wenn du nicht weiterkommst 😉

Grüße
Coco07!
Zum Vergrößern anklicken....

Es funktioniert jetzt.
Ich habe es jetzt gelöst, aber worauf du hinaus willst habe ich noch nicht ganz verstanden.
Warum tut das jetzt bei mir genau?


Java: 
public class Slipsize_too_small_Exception{
   
   
    public void text (int slipSize) throws SlipSizeTooSmallException{
       
        if (slipSize < 120 ){
           
            System.out.println("too small slipsize");
            throw new SlipSizeTooSmallException();
           
        }
        else{
            System.out.println("Successful, great Job");
        }   

    }

}



Java: 
public class SlipSizeTooSmallException extends Exception {

    public SlipSizeTooSmallException(){
       
        super("Slipsize of your girlfriend is greater than size you typed in");
    }
   
}



Java: 
public class Slipsize_too_small_Exception_Demo {

    public static void main(String[] args) throws SlipSizeTooSmallException{
       
        Slipsize_too_small_Exception exception = new Slipsize_too_small_Exception();
       
        exception.text(119);

    }

}
 
Ist nicht ganz so wild, dass du nicht verstehst, worauf ich hinaus will. Hauptsache du weißt jetzt, dass die Klasse selbst keine Exception werfen kann.

Ich habe aber eben übersehen, dass du auch in der Main-Methode die Exception an die nächst höhere Instanz "weiterreichst". Da die main-Methode aber der Start des Programms ist, stürzt dein Programm ab, weil es nichts "überhalb" der main-Methode gibt, welches die Exception irgendwie behandeln könnte.
Nimm deshalb die "throw-Anweisung" aus der Methodendefinition deiner main-Methode heraus und behandle die Exception stattdessen im Rumpf, ansonsten kannst du es auch gleich bleiben lassen und hättest das gleiche Ergebnis.

Grüße
Coco07!
 
ok, das muss ich jetzt verstehen, verstehe es aber nicht so ganz.
ich habe das Ganze jetzt so gemacht..
Ich habe ja keine Throw-Anweisung in meiner main??
die ist doch in der text-Methode von der class Slipsize_too_small_Exception

main
Java: 
public class Slipsize_too_small_Exception_Demo {

    public static void main(String[] args) throws SlipSizeTooSmallException{
       
        Slipsize_too_small_Exception exception = new Slipsize_too_small_Exception();
       
        exception.text(119);

    }

}



Java: 
public class SlipSizeTooSmallException extends Exception {

    public SlipSizeTooSmallException(){
       
        super("Slipsize of your girlfriend is greater than size you typed in");
    }
   
}


Java: 
public class Slipsize_too_small_Exception{
   
   
    public void text (int slipSize) throws SlipSizeTooSmallException{
       
        try{
        if (slipSize < 120 ){
            throw new SlipSizeTooSmallException();
        }else{
            System.out.println("Successful, great Job");
        }
        }
        catch(SlipSizeTooSmallException e)
        {
            System.out.println(e.toString() + ": too small slipsize");
        }
        }
    }
 
Diese Zeile ist gemeint:
Code: 
 public static void main(String[] args) throws SlipSizeTooSmallException{

Es wäre gut, wenn du hier auf das throws verzichtest und eine Ausnahme-Behandlung machen würdest. So wie coco07 es aufgezeigt hat.
 
Also anstatt in der text_methode?
Das würde ja heissen, ich behandle den selben Fehler 2 Mal, wenn ich die Ausnahmebehandlung in der Text_methode sein liesse und zusätzlich noch in der main es behandle
 
Also Deine Methode text wirft eine Exception. Das bedeutet, dass bei einem Aufruf (in deinem Fall die main Methode) entweder diese Exception abfangen (mittels try / catch) oder ebenfalls eine solche Exception werfen muss.

Was bei dir passiert ist:
- text wirft die Exception. Dadurch geht die AUsführung an main zurück.
- main fängt die Exception aber nicht, damit geht die Exception eine weitere Ebene nach oben.
- Eine weitere Ebene gibt es aber in Deiner Applikation nicht, d.h. die Runtime kümmert sich nun um die Exception.

Eine weitere Anmerkung von meiner Seite: Gewisse Standard-Situationen sollten dann auch die Standard-Exceptions nutzen. Wenn Du Argumente eines Aufrufes überprüfst, so bietet sich die IllegalArgumentException an. Diese muss auch nicht definiert werden.

Meine Meinung nacht ist es bei public Methoden immer wichtig, dass die Argumente vor der Nutzung geprüft werden. Und da ist es dann auch wichtig, dass die throws Klausel nicht an jeder Methode stehen muss 🙂 (Womit wir dann beim Thema checked / unchecked Exceptions sind! Eigene Exceptions kannst Du natürlich auch entsprechend schreiben - einfach von RuntimeException ableiten - https://docs.oracle.com/javase/7/docs/api/java/lang/RuntimeException.html)
 
Was du machst sind zwei Dinge:
a) In der Methode text prüfst Du die Argumente und wirfst ggf. eine Exception
b) In der main Methode reagierst Du auf die Exception. Das ist keine Prüfung mehr. Das ist dann eher ein: "Versuch eine bestimmte Sache - wenn dabei etwas schief geht, dann versuche ich einmal etwas anderes."

Typisches Beispiel ist hier z.B. ein Speicher-Vorgang. Das Speichern schlägt fehl (es tritt halt eine IO Exception auf) und die Applikation reagiert darauf, indem es z.B. einen "Speichern Unter" Dialog anzeigt.

Konrad
 
ok, meint ihr etwa so ist es richtig?

Java: 
public class Slipsize_too_small_Exception_Demo {
    public static void main(String[] args) {
        Slipsize_too_small_Exception exception = new Slipsize_too_small_Exception();
        int a = 119;
        try {
            if (a < 120) {
                throw new IllegalArgumentException();
            } else {
                exception.text();
            }
        } catch (IllegalArgumentException e) {
            System.out.println(e);
        }
    }
}

Java: 
public class IllegalArgumentException extends RuntimeException {
    public IllegalArgumentException(){      
        super("Slipsize of your girlfriend is greater than size you typed in");
    }  
}

Java: 
public class Slipsize_too_small_Exception{
    public void text (){      
            System.out.println("Successful, great Job, chose right size ");
        }
}
 
Zuletzt bearbeitet von einem Moderator:
Nein.
a) Du erstellst keine eigene Klasse IllegalArgumentException. Diese gibt es bereits. Es stiftet nur Verwirrung noch einmal eine Klasse mit dem gleichen Namen zu erstellen, auch wenn diese in einem anderen Namespace ist.
b) Jetzt war es ja kein Argument mehr, dass Du überprüfst. Desweiteren ist alles in einer Methode. Das macht keinen Sinn mehr. Du wirfst doch keine Exception um diese sofort wieder zu fangen!

Sinn der Exceptions ist es, einen Programmablauf an einer Stelle zu unterbrechen um den Fehler dann Ebene für Ebene zurück zu geben, bis die Exception endlich behandelt wird.

Also wenn Du eine Funktion schreibst, die etwas machen soll, aber diese kann nun überraschend nicht das tun, was sie tun soll: Dann gibt dies die Funktion zurück. Das ist wichtig, denn Du hast oft unterschiedliche Ebenen in Deiner Applikation. Der Code, der eine Datei schreibt, kennt nur das speichern von Daten in die Datei. Der Code ist universell und hat daher keinerlei Möglichkeit, auf Fehler zu reagieren. Denn diese Funktionalität kann ja von allen möglichen Routinen aufgerufen worden sein. Z.B. eine JavaFX Applikation, die dann ein SaveAs Fenster anzeigen könnte oder es ist eine Server-Applikation, die nun irgendwie reagieren muss aber keine Möglichkeit für eine User-UI hat.

Hilft das etwas beim Verständnis?

Konrad
 
Ich dreh mich hier seit 3h nur im Kreis, was muss ich jetzt genau machen?

Ist das kompliziert..

Was brauch ich jetzt eine Methode die eine Exception wirft..?
 
ok, mal Schritt für Schritt
hier ist die Methode, die müsste so ja stimmen
sie wirft jetzt eine Exception und ich fange sie nicht gleich auf..

Java: 
public class Slipsize_too_small_Exception{

    public void text(int a) throws IllegalArgumentException{

        if (a < 120) {
            throw new IllegalArgumentException();
        } else {
            System.out.println("well done");
        }
    }
}
 
Ja, schreib eine Methode mit Argumenten. Und definier irgend eine Regel, die erfüllt sein muss.

Also von mir aus schreibst Du eine Routine, die prüft, ob ein Mitarbeiter an einem bestimmten Tag bereits 10 jahre bei der Firma angestellt ist. Dazu nimmt die Methode zwei Daten: Einmal das Einstellungsdatum und zum anderen das Prüfdatum. Regeln, die du prüfen kannst, gibt es dann viele:
a) Prüfdatum vor Einstellungsdatum
b) Eines der beiden vor 1900
Und da kannst Du dann eine IllegalArgumentException werfen. Oder von mir aus irgend welche eigenen Exceptions.

Konrad
 
Ja richtig, damit hast Du eine Methode die ein Argument bekommt und Du hast eine Regel definiert. a muss größer oder gleich 120 sein. Du solltest aber noch beim Erstellen der Exception ein Nachricht mitgeben, also eher ein throw new IllegalArgumentException("a muss größer oder gleich 120 sein!");
Und ich würde da auf jeden Fall etwas Dokumentation generieren per JavaDoc, damit andere Entwickler beim nutzen der Methode diese Regel auch gleich sehen. Aber das sind andere Themen.

Konrad
 
kneitzel hat gesagt.:
Ja richtig, damit hast Du eine Methode die ein Argument bekommt und Du hast eine Regel definiert. a muss größer oder gleich 120 sein. Du solltest aber noch beim Erstellen der Exception ein Nachricht mitgeben, also eher ein throw new IllegalArgumentException("a muss größer oder gleich 120 sein!");
Und ich würde da auf jeden Fall etwas Dokumentation generieren per JavaDoc, damit andere Entwickler beim nutzen der Methode diese Regel auch gleich sehen. Aber das sind andere Themen.

Konrad
Zum Vergrößern anklicken....

Die dürfte dir besser gefallen ;P
so passt die Methode wohl oder?

irgendwie kann ich einstellungsdatum < 1900 || pruefdatum < 1900
nicht zu (einstellungsdatum || pruefdatum) < 1900 machen

Java: 
public class Slipsize_too_small_Exception{

    public void pruefen(int einstellungsdatum, int pruefdatum) throws IllegalArgumentException{
    
        if ((einstellungsdatum < pruefdatum) && (einstellungsdatum < 1900 || pruefdatum < 1900)) {
            System.out.println("Pruefdatum darf nicht kleiner sein als das Einstellungsdatum oder eines der beiden muss groesser 1900 sein");
            throw new IllegalArgumentException();
        } else {
            System.out.println("well done");
        }
    }
}
 
Zuletzt bearbeitet von einem Moderator:
so und

wenn das nicht stimmt, dann fress ich einen Besen 😛
das ist glaub gut so, bis auf die Benennung der Klassen oder?
Java: 
public class Slipsize_too_small_Exception_Demo {

    public static void main(String[] args) {

        Slipsize_too_small_Exception exception = new Slipsize_too_small_Exception();

        int einstellungdatum = 1899;
        int pruefungsdatum = 2012;
        try {
            exception.pruefen(einstellungdatum,pruefungsdatum);
            }
        catch (IllegalArgumentException e)
        {
            System.out.println(e);
        }
    }
}
Java: 
public class Slipsize_too_small_Exception{

    public void pruefen(int einstellungsdatum, int pruefdatum) throws IllegalArgumentException{
  
        if ((einstellungsdatum < pruefdatum) && (einstellungsdatum < 1900 || pruefdatum < 1900)) {
            System.out.println("Pruefdatum darf nicht kleiner sein als das Einstellungsdatum oder eines der beiden muss groesser 1900 sein");
            throw new IllegalArgumentException();
        } else {
            System.out.println("well done");
        }
    }
}
 
Zuletzt bearbeitet:
Was noch Sinn machen würde, wäre den Message Parameter der Exception abzufüllen. Dann steht auch etwas aussagekräftiges im StackTrace
 

Aktuelle Jobs

Neue Themen

Ähnliche Themen

Verwendung von unchecked exceptions & bereits vorhandenen exceptions was priorisieren
Antworten: 3
Aufgabe: Eingaben prüfen, Exceptions
Antworten: 7
Problem Vererbung/Exceptions
Antworten: 9
Frage zu Exceptions
Antworten: 12
Eigene Fehlermeldungen bei Exceptions
Antworten: 19

Zurück
Oben