Java - eigene Exceptions

  • Ich möchte in Java eine eigene Exception als Unterklasse von Exception schreiben, beim Kompilieren bekomme ich folgende Fehlermeldung:

    'exception MyException is never thrown in body or corresponing try statement'

    Warum wird diese MyException nicht geworfen? Das ist der Code:

    -----

    import java.io.*;

    public class Beispiel11{

    public static void main (String[] args) throws IOException{

    System.out.println ("Zahl eingeben:");
    try {
    BufferedReader ein = new BufferedReader(new InputStreamReader(System.in));
    int x=Integer.parseInt(ein.readLine());
    primFakt(x,2);
    } catch (MyException me){
    System.err.println(me.toString());
    }
    }


    public static void primFakt (int x, int i){
    .. ..
    }


    class MyException extends Exception{

    public MyException(){
    super ("keine Integerzahl eingegeben");
    }
    }

  • Zitat von Sicka

    Ich möchte in Java eine eigene Exception als Unterklasse von Exception schreiben, beim Kompilieren bekomme ich folgende Fehlermeldung:

    'exception MyException is never thrown in body or corresponing try statement'

    Warum wird diese MyException nicht geworfen?

    hast Du irgendwo ein throw(new MyException())?

    Schau Dir mal das Exceptionhandling im Einheitenberechner an, einfach die dortige Exception durch MyException ersetzen // René

  • Ich nehme mal an du wirfst MyException in primFakt(...) aus.

    Da du MyException aber in main(...) und wahrscheinlich nicht in primFakt(...) auffängst, muss primFakt(...) MyException ans rufende (Haupt-)Programm auswerfen können.

    Also:

    public static void primFakt(int x, int i) throws MyException {
    ...
    }

    Hoffe das hilft!

    paradiso -> purgatorio -> inferno

  • hi!

    mein java ist zwar auch schon ein wenig her, aber i versteh ned ganz, wofür deine parseException methode steht!? zumindest finde ich laut 1.4 api reference keine gleiche (virtuelle) methode, die nötigenfalls überschrieben werden müßte.


    normalerweise reicht eine einfache ableitung mit implementation der konstruktoren, die nur wiederum die basiskonstruktoren aufrufen.





    lg

  • hallo!

    du kannst nicht eine exception-klasse auffangen, die spezieller oder anders ist, als die die geworfen ist.

    dh:

    Exception
    |
    |_ NumberFormatException << wird von parseInt geworfen
    |_ MyException << willst du auffangen

    Wie gesagt, du kannst nur entweder eine Exception auffangen, die tatsächlich geworfen wird (hier NumberFormatException) oder eine allgemeinere (hier zb Exception).

    welche exceptions eine methode wirft, kannst du in der java api spezifikation nachsehen. für j2SE 1.4.2 wäre das zb:

    http://java.sun.com/j2se/1.4.2/docs/api/

    in deinem fall würde ich einfach catch (NumberFormatException nfe) {} schreiben...

    hth,
    lg michi

  • Zitat von rck

    Würde er dann nicht eine Meldung der Art "primFakt() throws Exception MyException, but hasn't declared so" bekommen?

    Ich bin mir nicht 100%ig sicher (auch mein Java liegt schon ein Semester zurück), aber ich glaube - nein:
    Es ist ja prinzipiell kein Problem, eine Exception in primFakt(...) auszuwerfen, man könnte sie ja auch wieder innerhalb von primFakt(...) fangen. Geschieht dies zur Laufzeit nicht, muss die Exception ins rufende Programm weitergeworfen werden (was im Programm des OP wegen fehlendem "throws ..." nicht möglich ist), oder das Java-Programm terminiert sofort mit einer Fehlermeldung. Beim Compilieren hingegen tritt soweit ich weiss in keinem dieser beiden Fälle ein Fehler auf (genau weiss ich es aber nicht, bin zu faul jetzt einen Java-Compiler zu installieren).

    Die Compiler-Fehlermeldung des OP bezieht sich meiner Meinung nach lediglich darauf, dass im catch-Block MyException gefangen wird, diese jedoch im zugehörigen try-Block nicht ausgeworfen werden kann (primFakt(...) wirft überhaupt keine Exceptions aus und die anderen Anweisungen werfen ihre eigenen spezifischen Exceptions aus).

    lg

    edit:
    Ich hab gerade das Posting von michi204 gelesen, er hat völlig Recht.
    Auf die Idee, dass Sicka MyException auf diese Weise verwenden wollte, bin ich gar nicht gekommen. Ich nahm fix an, er wirft MyException in primFakt(...).

    paradiso -> purgatorio -> inferno

  • Zitat von rck

    Er verwendet das Ding scheinbar als Konstruktor, sollte wohl MyException() heißen? Ist auf jeden Fall verdreht... :)

    So ist es, das ist der Konstuktor und soll natürlich MyException heißen, ich habe es oben ausgebessert.

    Wenn beim Parsen ein Fehler auftritt, soll nicht die NumberFormatException auftreten, sondern die MyException. (auch wenn es hier nicht viel Sinn macht)
    Ich denke, wenn im try-Block ein Fehler auftritt, wid die Exception geworfen, die im catch-Block steht, warum funktioniert das dann hier nicht?

  • Zitat von Sicka


    Ich denke, wenn im try-Block ein Fehler auftritt, wid die Exception geworfen, die im catch-Block steht, warum funktioniert das dann hier nicht?

    FALSCH, im try-Block wird die Exception geworfen, die eben erzeugt wird (entweder selbst mit throw ... oder durch eine Funktion, die Exceptions wirft).
    Im Catch-Block musst du dann genau diese Exception fangen oder zumindest eine Oberklasse davon (im Zweifelsfall vom Typ Exception). Bei parseInt ist das NumberFormatException und deswegen wird sie auch bei falschem Format geworfen.
    Wenn du eigene Exceptions fangen willst, musst du sie vorher auch werfen, wenn irgendwo ein Fehler auftritt, und zwar z.B. mit "throw new MyException()" im try-Block (entweder direkt oder indirekt über eine selbst gebaute Funktion, die deine Exceptions wirft).

    Bei vordefinierten Funktionen musst du aber die Exceptions fangen, die vordefiniert sind (siehe Dokumentation), oder du baust dir eine Hilfsfunktion, die diese Exception fängt und daraufhin deine eigene weiterwirft, was aber in dem Fall wohl eher unnötig ist.

    Ich hoffe, das stimmt so in etwa.

    "Sausen Sie mit mir ins Laplace-Land" - KAISER 4ever :D

  • templar hat recht. wenn du unbedingt die myexception haben willst musst du hier wohl so vorgehen:

    try
    {
    ...
    ...parseInt...
    ...
    }
    catch (NumberFormatException nfe)
    {
    throw new myException();
    }

    aber ich bin wirklich neugierig und hoffe dass du uns auch verrätst, wozu du unbedingt die myException brauchst.

    lg michi

  • Zitat von Sicka

    So ist es, das ist der Konstuktor und soll natürlich MyException heißen, ich habe es oben ausgebessert.

    Wenn beim Parsen ein Fehler auftritt, soll nicht die NumberFormatException auftreten, sondern die MyException. (auch wenn es hier nicht viel Sinn macht)
    Ich denke, wenn im try-Block ein Fehler auftritt, wid die Exception geworfen, die im catch-Block steht, warum funktioniert das dann hier nicht?

    Im catch-block werden exceptions nicht geworfen, sondern abgefangen.

    um eine exception zu werfen, kannst du das throws keyword verwenden.
    die methode Integer.parseInt(), die du in deinem beispiel verwendest, sieht z.B. ca so aus:

    Code
    public int parseInt(String s)
    		throws NumberFormatException
        {
            if (s == null) {
                throw new NumberFormatException("null");
            }
            //...
        }

    wenn also z.B der String s null ist, wird mit throw eine NumberFormatException geworfen. diese exception kann jetzt entweder sofort abgefangen werden (mit try/catch), oder wie hier mit dem 'throws NumberFormatException' im methodenheader an die stelle weitergegeben werden, in der die methode aufgerufen wird.

    sinn und zweck des ganzen ist es nun, das eben diese NumberFormatException _immer_ irgendwo abgefangen werden muss. Nur so ist sichergestellt, das du den Fall, das zum beispiel der übergebene String null ist, auch berücksichtigst.

    du kannst natürlich die NumberFormatException abfangen, und als reaktion eine MyException werfen. das sähe dann zum beispiel so aus:

    du kannst auch einfach schreiben:


    , denn sowohl NumberFormatException als auch IOException sind ja auch Exceptions. Dieses 'sammeln' von Exceptions ist aber mit Vorsicht zu geniessen, da unterschiedliche fehler eventuell eine unterschiedliche behandlung erfordern.

  • Zitat von Sicka

    Ich denke, wenn im try-Block ein Fehler auftritt, wid die Exception geworfen, die im catch-Block steht, ...


    Das ist definitiv falsch!
    Tritt im try-Block ein Fehler beim Parsen in Integer.parseInt(...) auf, wird immer die NumberFormatException geworfen, egal welche Exception du im catch-Block zu fangen versuchst.

    Zitat von Sicka

    Wenn beim Parsen ein Fehler auftritt, soll nicht die NumberFormatException auftreten, sondern die MyException. (auch wenn es hier nicht viel Sinn macht)


    Ein "Workaround" dafür wäre, NumberformatException zu fangen und anschließend MyException zu werfen. Diese "Technik" nennt man "re-throwing" und sie ist im allgemeinen (wie du selbst zugeben musst) nicht sehr sinnvoll:

    paradiso -> purgatorio -> inferno

  • Danke an alle, jetzt ist alles klar

    michi204: es gibt keinen besonderen Grund, warum ich unbedingt die MyException wollte, ich probiere nur ein bisschen herum deshalb wollte ich das so, auch wenn es hier keinen Sinn macht

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!