Throws Exception deklaration in Methoden

[macap]

Hallo,

ich habe mir schon immer die Frage gestellt,
warum im C#-Standard nicht die Möglichkeit definiert wurde,
dass man Methoden coden kann die explizit bei Verwendung mit einer Exception abgefangen werden müssen.


Viele werden das wahrscheinlich aus Java kennen.

Java-Beispiel:

public void myMethod() throws MyPersonalException
{
// do something
}

wenn ich jetzt myMethod verwenden möchte,
dann muss ich explizit einen try catch darum bauen:


try
{
myMethod();
}
catch(MyPersonalException e)
{
// abfangen....
}


Kennt jemand den Grund warum es diese Möglichkeit nicht gibt?
Ist das vielleicht mit C# anders lösbar?


Für mich war es damals in Java immer eine Möglichkeit "relativ" sicheren und sauberen Code zu schreiben, weil ich einfach bei Verwendung der Methode schon erkennen kann, dass möglicherweise eine Exception auftreten könnte.



Bye,
Martin

[Christian Marquardt]

Für mich war es damals in Java immer eine Möglichkeit "relativ" sicheren und sauberen Code zu schreiben,

???

public void myMethod() throws MyPersonalException

Damit hast du in Java die in der Methode aufgetretene Exception nicht gefangen, sondern nur an den Aufrufer weitergereicht. Dieses Weiterreichen gibt es unter C# m.E. nicht. IMHO würde ich das Weiterreichen auch nicht unbedingt als sauber ansehen...wie gesagt IMHO....

Keiner hindert dich jedoch, die Exception dort zu fangen und zu behandeln wo sie auftritt. Auch kannst du mit throw new .....Exception(); Exceptions werfen.

[macap]

???

Damit hast du in Java die in der Methode aufgetretene Exception nicht gefangen, sondern nur an den Aufrufer weitergereicht. Dieses Weiterreichen gibt es unter C# m.E. nicht. IMHO würde ich das Weiterreichen auch nicht unbedingt als sauber ansehen...wie gesagt IMHO....

Wo habe ich geschrieben, dass ich sie damit abgefrangen habe?

Klar habe ich sie weiter gereicht.
Deswegen ja das try catch in meinem Beispiel

Aber ich werde eben GEZWUNGEN sie weiter zu reichen, weil es sosnt einen Compiler-Fehler gibt mit missing-try-catch-block.

Ich finde es sehr sauber, weil ich wie gesagt bereits bei Verwendung der Methode sehe, dass hier eine Exception autreten könnte und nicht erst bei der Laufzeit.

Insbesondere wenn die Methode nicht meine eigene ist und ich den Code der Methode nicht kenne.


Bye,
Martin

[Christian Marquardt]

Aber ich werde eben GEZWUNGEN sie weiter zu reichen, weil es sosnt einen Compiler-Fehler gibt mit missing-try-catch-block.

Nein, du kannst sie fangen ODER weiterreichen

[Frischmilch]

Easy Jungs. Wenn eine Methode mit "..throws <Exception>" deklariert wird, dann muss der Aufrufer, entweder ein try-catch Block um den Methodenaufruf basteln, oder er kann die Exception wieder eine Ebene weiter nach oben durchreichen. Ob das mit so einem verketteten durchreichen von Exception schöner Programmierstil ist, sei in diesem Fall einmal egal. Wenn ich macap richtig verstanden habe gehts lediglich darum, dass man als Programmierer gezwungen wird, Exceptions zu behandeln, wenn man eine Methode aufruft, welche "throw" im Methodenkopf hat. Und das ist vollkommen richtig.

Was evtl. funktionieren könnte:
Wenn der Compiler Warnungen erzeugen kann bei nicht behandelten Exceptions, dann gibts in den Projekteinstellungen die Möglichkeit diese Warnungen als Fehler zu behandeln. Allerdings habe ich da wenig Hoffnung. (Evtl. mal mit dem Warning-Level spielen?)

[macap]

@Frischmilch. Vielen Dank. Du hast mir quasi das Wort aus dem Mund genommen.

Danke für den Tipp mit Deiner Notlösung. Das funktioniert aber dann, so wie ich Deine Beschreibung lese, nur bei nicht behandelten Exceptions im Standard-Framework,
weil mir ja bei eigenen Methoden/Klasen und eigenen Exceptions genau dieses fehlt, oder?


Bye,
Martin

[Christian Marquardt]

dann muss der Aufrufer, entweder ein try-catch Block um den Methodenaufruf basteln, oder er kann die Exception wieder eine Ebene weiter nach oben durchreichen.

Genau diesen Sachverhalt habe ich erläutert, weil

Aber ich werde eben GEZWUNGEN sie weiter zu reichen, weil es sosnt einen Compiler-Fehler gibt mit missing-try-catch-block.

so nicht richtig ist.

[macap]

Genau diesen Sachverhalt habe ich erläutert, weil

Aber ich werde eben GEZWUNGEN sie weiter zu reichen, weil es sosnt einen Compiler-Fehler gibt mit missing-try-catch-block.

so nicht richtig ist.

Ok dann hat hier wohl ein "oder" gefehlt, d.h.

"... ich werde gezwungen sie weiter zu reichen oder einen try-catch-block darum zu bauen."
Ich könnte jetzt argumentieren, dass man sich dieses "oder" obligatorisch hätte dabei denken können, weil ich von "missing-try-catch-block" geschrieben habe und man daher sinnvollerweise auch einen try-catch einbinden kann um den Compilerfehler zu beheben


Spass beiseite...

Ich hoffe wir haben jetzt geklärt was ich meinte.
Meine eigentliche Frage ist allerdings nur zum Teil beantwortet worden.

Anscheinend geht dies in C# nicht und ist auch nicht angedacht,
aber kann mir jemand sagen warum das so ist?


Bye,
Martin

[Christian Marquardt]

Komisch, wenn man bei Fragenden etwas unterstellt -> nicht gut; wenn man alles versucht genau zumachen -> nicht gut

aber kann mir jemand sagen warum das so ist?

Spätenstens Mircosoft

[Ralf Jansen]

Die Entwickler des Frameworks haben sich explizit gegen checked Exceptions entschieden. Zusammengefasst ist die Meinung wohl das checked Exceptions das eigentlich Problem nicht wirklich lösen und durch den Overhead eher mehr Probleme schaffen als lösen.

Siehe dazu zum Beispiel dieses Interview mit Anders Hejlsberg.

[macap]

Ahh danke!

Genau das hatte mich interessiert ;-)