[EXCEPTIONS] RuntimeException muss nicht gefangen werden?
Hendrick Kay
zur RuntimeException steht in der API-Doku:
"RuntimeException is the superclass of those exceptions that can be thrown
during the normal operation of the Java Virtual Machine.
A method is not required to declare in its throws clause any subclasses of
RuntimeException that might be thrown during the execution of the method but not
caught."
1. Wieso müssen RuntimeExceptions nicht mit "throws" in der Methode deklariert
werden?
2. Wieso muss die RuntimeException nicht mit einem try-catch-Block gefangen
werden?
Hat das einen tieferen Sinn? Ich sehe es im Moment als Lücke der sonst strengen
Handhabung
von Exceptions.
Ciao
Hendrick
Christian Hauser
> Hi,
>
> zur RuntimeException steht in der API-Doku:
>
> "RuntimeException is the superclass of those exceptions that can be thrown
> during the normal operation of the Java Virtual Machine.
>
> A method is not required to declare in its throws clause any subclasses of
> RuntimeException that might be thrown during the execution of the method but not
> caught."
>
> 1. Wieso müssen RuntimeExceptions nicht mit "throws" in der Methode deklariert
> werden?
siehe unten.
> 2. Wieso muss die RuntimeException nicht mit einem try-catch-Block gefangen
> werden?
RuntimeExceptions sind Laufzeitfehler, die man als Programmierer
abfangen kann, aber nicht muss. Warum weiss ich auch nicht wirklich.
Hat wahrscheinlich damit zu tun, dass das Fehler-Handling in Java
sonst sehr sehr aufwendig würde, wenn man alle möglichen Exceptions
abfangen müsste.
Gruss, Hausi
David Zerrenner
> 1. Wieso müssen RuntimeExceptions nicht mit "throws" in der Methode deklariert
> werden?
> 2. Wieso muss die RuntimeException nicht mit einem try-catch-Block gefangen
> werden?
>
> Hat das einen tieferen Sinn? Ich sehe es im Moment als Lücke der sonst strengen
> Handhabung
> von Exceptions.
Belehrt mich, wenn ich falsch liege, aber ich glaube, da hält man sich
ein Hintertürchen offen. Bei unserem EJB-Container z.B. darf man die gar
nicht selber werfen, weil der Server dann den Löffel abgibt, sprich, er
fängt die RuntimeException selbst und beendet sich dann. In der Doku
stand dazu, dass man es halt vermeiden sollte, RuntimeExceptions zu
werfen.
RuntimeExceptions treten ja - wie der Name schon sagt - zur /Laufzeit/
auf. Zur Compilezeit weiss man nicht, wo und warum. Dann müsste man ja
bei jedem Befehl eine RuntimeException fangen...
> Ciao
> Hendrick
tschö,
David
Christian Hauser
>> deklariert
>> werden?
>
>
>
> siehe unten.
>
>> 2. Wieso muss die RuntimeException nicht mit einem try-catch-Block
>> gefangen
>> werden?
>
>
>
> RuntimeExceptions sind Laufzeitfehler, die man als Programmierer
> abfangen kann, aber nicht muss. Warum weiss ich auch nicht wirklich. Hat
> wahrscheinlich damit zu tun, dass das Fehler-Handling in Java sonst sehr
> sehr aufwendig würde, wenn man alle möglichen Exceptions abfangen müsste.
>
> Gruss, Hausi
>
Ich kann noch anfügen, dass RuntimeExceptions eigentlich auf
Programmierfehler hindeuten und eine passende Reaktion auf die
Exception meistens nur eine Symptombekämpfung ist (und von schlechtem
Programmierstil zeugt).
NullPointerExceptions oder ArrayIndexOutOfBoundsExceptions sind solche
Beispiele, auf die zwar reagiert werden kann, jedoch in den meisten
Fällen das Programm überarbeitet werden müsste.
Uwe Plonus
> Hendrick Kay schrieb:
>
>> 1. Wieso müssen RuntimeExceptions nicht mit "throws" in der Methode
>> deklariert
>> werden?
>> 2. Wieso muss die RuntimeException nicht mit einem try-catch-Block
>> gefangen
>> werden?
>>
>> Hat das einen tieferen Sinn? Ich sehe es im Moment als Lücke der sonst
>> strengen
>> Handhabung
>> von Exceptions.
>
>
> Belehrt mich, wenn ich falsch liege, aber ich glaube, da hält man sich
> ein Hintertürchen offen. Bei unserem EJB-Container z.B. darf man die gar
> nicht selber werfen, weil der Server dann den Löffel abgibt, sprich, er
> fängt die RuntimeException selbst und beendet sich dann. In der Doku
> stand dazu, dass man es halt vermeiden sollte, RuntimeExceptions zu
> werfen.
Ich weiß nicht, was Du mit Hintertürchen meinst...
Uwe
Uwe Plonus
Ja, das hat einen tieferen Sinn.
RuntimeExceptions sollten im normalen Programmlauf nicht auftreten, wenn
alles richtig programmiert ist, daher müssen diese nicht gefangen
werden. Beispiel:
ArrayIndexOutOfBoundsException: Wenn diese Exception geflogen kommt,
dann hast Du vorher vergessen die Größe des Arrays abzufragen und
greifst daher auf einen Index zu, den es nicht gibt.
Dies war jedenfalls die Intention von Sun, teilweise sind die Exceptions
aber nicht ganz korrekt zugeordnet...
Uwe
Christian Flügel
> 1. Wieso müssen RuntimeExceptions nicht mit "throws" in der Methode
deklariert
> werden?
> 2. Wieso muss die RuntimeException nicht mit einem try-catch-Block
gefangen
> werden?
Runtime Exceptions sind solche Exceptions bei denen in der Regel das
Abfangen gar keinen Sinn macht. Zum Beispiel Division by Zero,
ArrayIndexOutOfBounds, NumberFormatException, Segmentation Fault etc.. Sie
werden nicht im Java Code sondern in der virtuelllen Maschine selbst
erzeugt.
Das Abfangen von solchen Exceptions ist zwar möglich, macht jedoch
eigentlich kaum Sinn da eine solche Exception auf einen Fehler hinweist bei
dem nur noch ein kompletter Abbruch des Programms sinnvoll ist. Deshalb
macht es auch keinen Sinn das RuntimeExceptions defaultmäßig vom
Programmierer gefangen werden müssen, stellt doch der Programmabbruch in den
meisten Fällen die beste oder einzig mögliche Lösung dar.
MfG
Christian
Stephan Menzel
> Hi,
Hallo Hendrik,
> 1. Wieso müssen RuntimeExceptions nicht mit "throws" in der Methode
> deklariert werden?
weil sie IMHO definitionsgemaess nicht vorhersehbar sind und demnach
nicht gefangen werden koennen.
> 2. Wieso muss die RuntimeException nicht mit einem try-catch-Block
> gefangen werden?
Deswegen.
RTEs sollen auftreten um anzuzeigen, dass etwas grundsaetzlich
schieflief und daher vom Programmierer vermieden werden muessen.
Waehrend der Entwicklungszeit koennen die auftreten und man reagiert
entsprechend. Wenn die Weichware 'Stable' wird, dann sollten
Runtimeexceptions ausbleiben oder auf nicht programminterne und
fassbare Ursachen zurueckzufuehren sein.
Offen gesagt bin ich auch noch nie auf die Idee gekommen (catch
RuntimeException) zu schreiben. Ausser jetzt natuerlich.
Stephan, Senf dazugebend
--
Referenzen:
http://www.mptrans.de/mbdag/posting/80.html
http://www.mptrans.de/mbdag/posting/82.html
Stephan Menzel
> Runtime Exceptions sind solche Exceptions bei denen in der Regel das
> Abfangen gar keinen Sinn macht. Zum Beispiel Division by Zero,
Argl![tm]
> ArrayIndexOutOfBounds,
Hmm. Hab' ich vor wenigen minuten eine gefangen. Das sollte schon drin
sein und ist IMHO keine 'richtige' RTE.
> NumberFormatException,
Erst recht nicht.
Die faengt man doch dauernd beim Stringauswerten und sowas.
Da kann ich nicht zustimmen.
> Segmentation Fault
Das auf jeden Fall.
Hab' ich aber noch nie gesehen.
Stephan 'Zerodivider' Menzel, gruessend
Uwe Plonus
Das ist jetzt nicht nachvollziehbar. Warum sollte das Programm
abbrechen, wenn ich eine division durch 0 habe? Es kann doch sein, daß
ich dann mit einem sinnvollen default-Wert weiterarbeiten kann. Es ist
natürlich besser, diese Fehlerbedingung vorher abzufragen Bsp:
if (c == 0) {
a = b/c;
} else {
a = b/0.01;
}
Was Du jetzt mit dort eingeworfen hast sind die Errors, welche keinen
Sinn machen abgefangen zu werden, da das Programm meistens nicht weiter
lauffähig ist (OutOfMemoryError oder Segmentation Fault).
Uwe
Sönke Müller-Lund
>>1. Wieso müssen RuntimeExceptions nicht mit "throws" in der Methode
>>deklariert werden?
>
>
> weil sie IMHO definitionsgemaess nicht vorhersehbar sind und demnach
> nicht gefangen werden koennen.
Genau.
Der Compiler kann i.A. nicht erkennen, ob z.B.
x.toString();
eine NullPointerException oder
(String)x.next();
eine ClassCastException auslöst.
>>2. Wieso muss die RuntimeException nicht mit einem try-catch-Block
>>gefangen werden?
>
>
> Deswegen.
ich füge noch hinzu, dass jede Methode implizit die throw-Klausel für
eine RTE besitzt, d.h.
void foo()
und
void foo() throws RuntimeException
haben exakt die selbe Signatur.
(Versucht das mal mit einer anderen Exception bei der Implementierung
eines Interfaces)
Sönke
Christian Hauser
> if (c == 0) {
> a = b/c;
> } else {
> a = b/0.01;
> }
äh... meinst du es so?
if (c != 0)
Martin Erren
> > Segmentation Fault
>
> Das auf jeden Fall.
> Hab' ich aber noch nie gesehen.
Das wäre auch eher ein Error. Bei Errors hat der (Java-)Programmierer
nix falsch gemacht. Errors und RuntimeExceptions muss man nicht fangen,
darf man aber allemal, falls es einem Sinn macht:
int parseSecure(String s) {
try {
return Integer.parseInt(s);
} catch(NumberformatException(nfe) {
return 0;
}
}
RuntimeExceptions gehen von einem vordefinierten Zustand aus.
z.B. variable!=null, hier parsable int.
Ob im Design eine RuntimeException oder eine andere zu wählen
ist, liegt nat. im Ermessen des SW-Designers.
> Stephan 'Zerodivider' Menzel, gruessend
Martin, rezerodivididing.
--
System.out.println("To "+(42d/0)+" ... and beyond!");
Christian Flügel
> > ArrayIndexOutOfBounds,
>
> Hmm. Hab' ich vor wenigen minuten eine gefangen. Das sollte schon drin
> sein und ist IMHO keine 'richtige' RTE.
Wieso. Man kann das doch ganz einfach über Array.length abprüfen. Wenn eine
ArrayIndexOutOfBoundsException geworfen wird hat der Programmierer einen
Fehler gemacht und sollte wohl besser den Code überarbeiten als die
Exception auch noch zu fangen.
> > NumberFormatException,
>
> Erst recht nicht.
> Die faengt man doch dauernd beim Stringauswerten und sowas.
> Da kann ich nicht zustimmen.
Mmmh. Ich habe gerade mal nachgesehen, die ganzen decode(String) Funktionen
werfen tatsächlich NumberFormatExceptions. Das ist imho inkonsequent gelöst
von Sun. Gerade bei Textfeldern kommt es doch recht oft vor das man String
to Number Conversions machen muß, das sollte wohl besser eine normale
Exception sein.
> > Segmentation Fault
>
> Das auf jeden Fall.
> Hab' ich aber noch nie gesehen.
OK ist nicht wirklich ne Java Exception Ich wollte nur meinen Punkt
verdeutlichen. (Ich habe allerdings auch schon JVMs segfaulten sehen)
MfG
Christian
Edwin Günthner
Stephan Menzel wrote:
>
> > ArrayIndexOutOfBounds,
>
> Hmm. Hab' ich vor wenigen minuten eine gefangen. Das sollte schon drin
> sein und ist IMHO keine 'richtige' RTE.
Diese Exception solltest Du aber nicht bekommen! Wenn Du sie
bekommst, ist Dein Code falsch.
>
> > NumberFormatException,
>
> Erst recht nicht.
> Die faengt man doch dauernd beim Stringauswerten und sowas.
> Da kann ich nicht zustimmen.
Das stimmt - diese Exception gehört ja praktisch zum alltäglichen
Handwerkszeug - wenn eine Anwendung deswegen runterfällt
gehört der Programmierer hinterhergeworfen.
David Zerrenner
>> Belehrt mich, wenn ich falsch liege, aber ich glaube, da hält man sich
>> ein Hintertürchen offen. Bei unserem EJB-Container z.B. darf man die gar
>> nicht selber werfen, weil der Server dann den Löffel abgibt, sprich, er
>> fängt die RuntimeException selbst und beendet sich dann. In der Doku
>> stand dazu, dass man es halt vermeiden sollte, RuntimeExceptions zu
>> werfen.
>
> Ich weiß nicht, was Du mit Hintertürchen meinst...
Naja, abgesehen von den Gründen, die in den anderen Postings stehen,
meine ich mit Hintertürchen eben z.B. den Fall, dass wirklich was
schlimmes passiert (Segmentation Fault etc.). Was machst Du dagegen?
In dem Fall wird eine Exception geworfen, aber du kannst nie
vorhersehen, wo.
Vielleicht auch für den Fall, dass dein Code innerhalb irgendeiner
Engine läuft (EJB-Conteiner, Servlets, etc.). Da können die Container
diese Exceptions fangen.
tschö,
Dazer.
Stephan Menzel
[ArrayIndexOutOfBounds]
> Wieso. Man kann das doch ganz einfach über Array.length abprüfen. Wenn
> eine ArrayIndexOutOfBoundsException geworfen wird hat der Programmierer
> einen Fehler gemacht und sollte wohl besser den Code überarbeiten als
> die Exception auch noch zu fangen.
Ja, schon.
Die Macht der Bequemlichkeit eben.
Man balstelt an irgendwas rum, ploetzlich tritt bei einem Test sowas
auf, man weiss warum und will es erstmal ignorieren, schnell gecatched
und es bleibt drinnen. Ist unperformater, scheusslich zu lesen und
allgemein verachtenswert aber was solls! Meistens passiert mir das bei
diesen Methoden, die ein Array von irgendwas liefern, von denen man
aber nur den ersten Wert braucht und deswegen das [0] hartkodiert
drinnen hat.
*schnell den Code ueberarbeit*
Aber Du hast recht, die Mistkerle duerfen nicht auftreten.
> Mmmh. Ich habe gerade mal nachgesehen, die ganzen decode(String)
> Funktionen werfen tatsächlich NumberFormatExceptions. Das ist imho
> inkonsequent gelöst von Sun. Gerade bei Textfeldern kommt es doch recht
> oft vor das man String to Number Conversions machen muß, das sollte
> wohl besser eine normale Exception sein.
Naja, was ist eine 'normale Exception' NFEs treten zu Laufzeit auf,
also sind sie RTEs. Das ist schon konsequent dem Ansatz gefolgt. Ich
war eben auch ueberrascht als ich feststellte, wie viele Exceptions
eigentlich RTEs sind.
Stephan, trys ausbauend
Ingo R. Homann
>
> Belehrt mich, wenn ich falsch liege, aber ich glaube, da hält man sich
>
> RuntimeExceptions treten ja - wie der Name schon sagt - zur /Laufzeit/
> auf. Zur Compilezeit weiss man nicht, wo und warum. Dann müsste man ja
> bei jedem Befehl eine RuntimeException fangen...
>
> David
Ehm, also da muss ich in der Tat mal belehren! ;-)
Zur Compilezeit weiss man so gut wie nie, wo und warum eine Exception
geworfen wird, das ist nicht nur bei RauntimeExceptions der Fall, denn
*jede* Exception tritt zur Laufzeit auf. Insofern ist der Name
"RuntimeException" vielleicht etwas ungeschickt gewählt (danke für den
Hinweis, ist mir bisher noch gar nicht aufgefallen, hab' auch nie drüber
nachgedacht!)
Als "Hintertürchen" sehe ich es auch eher nicht, obwohl man es sicher
als solches missbrauchen könnte.
Alles andere ist glaube ich schon in diesem Thread (bzw. einem anderen
Sub-Thread) gesagt worden, daher schließe ich mich dem Rest wortlos an.
;-)
Ciao,
Ingo
Stephan Menzel
> > Hmm. Hab' ich vor wenigen minuten eine gefangen. Das sollte schon drin
> > sein und ist IMHO keine 'richtige' RTE.
>
> Diese Exception solltest Du aber nicht bekommen! Wenn Du sie
> bekommst, ist Dein Code falsch.
Jaaa, s.o.
Ihr habt recht! Ach Du schande, jetzt hab' ich mich als Coderschlampe
geoutet.
Stephan, tausendfache Entschuldigungen bekanntgebend
Ingo R. Homann
>
> Hendrick Kay wrote:
>
> > Hi,
>
> Hallo Hendrik,
>
> > 1. Wieso müssen RuntimeExceptions nicht mit "throws" in der Methode
> > deklariert werden?
>
> weil sie IMHO definitionsgemaess nicht vorhersehbar sind und demnach
> nicht gefangen werden koennen.
Blödsinn! (Sorry!) So gut wie jede Exception ist *im Allgemeinen*
*nicht* "vorhersagbar" (*), egal ob RuntimeException oder nicht. Und
gefangen werden kann sie sowieso trotzdem!
> RTEs sollen auftreten um anzuzeigen, dass etwas grundsaetzlich
> schieflief und daher vom Programmierer vermieden werden muessen.
> Waehrend der Entwicklungszeit koennen die auftreten und man reagiert
> entsprechend. Wenn die Weichware 'Stable' wird, dann sollten
> Runtimeexceptions ausbleiben oder auf nicht programminterne und
> fassbare Ursachen zurueckzufuehren sein.
Dazu vollstens ACK!
> Offen gesagt bin ich auch noch nie auf die Idee gekommen (catch
> RuntimeException) zu schreiben. Ausser jetzt natuerlich.
Jein. IdR ist es nicht sinnvoll, da hast Du sicher recht. Aber wenn ich
z.B. einen ServletServer schreibe, kann es schon ziemlich sinnvoll sein,
daß ein kaputtes Servlet nicht gleich den ganzen Server abschießt,
sondern daß der ServletServer diese Exception fängt und irgendwohin
loggt, ggf. noch den offenen Request korrekt behandelt, etc...
Ciao,
Ingo
(*)(wobei sich natürlich für jede Exception (RTE oder nicht) auch
spezielle Fälle konstruieren lassen, bei denen sie vorhersagbar sind)
Christian Flügel
> Jaaa, s.o.
> Ihr habt recht! Ach Du schande, jetzt hab' ich mich als Coderschlampe
> geoutet.
Nanu das ist jetzt schon der zweite durchaus SIGbare Ausspruch von dir in
diesem Thread ;-) da weiß man ja garnicht welchen man zuerst nehmen soll.
:-D.
MfG
Christian
Michael Schmidt
>
> Jaaa, s.o.
> Ihr habt recht! Ach Du schande, jetzt hab' ich mich als Coderschlampe
> geoutet.
>
Ich wußte es! ;)
Aber so ist es, mal zum Testeen was hingeworfen und dann für ernsthafte
Sachen angewöhnt.
Micha
--
Homepage & FAQ von de.comp.lang.java: http://www.dclj.de
Ingo R. Homann
> ...
> Ihr habt recht! Ach Du schande, jetzt hab' ich mich als Coderschlampe
> geoutet.
OK, "Carla" und ich nennen dich ab jetzt "Stephanie" ;-)
SCNR,
Ingo, zeromultiplyer ;-)
Ingo Horn
Hä?
war das nicht der Zerodivider? Oder hab ich da was falsch in
Erinnnerung...
Ingo, in Erinnerungen kramend
--
Ein Bankier ist ein Mensch, der seinen Schirm verleiht,
wenn die Sonne scheint, und ihn sofort zurückhaben will,
wenn es zu regnen beginnt.
[Mark Twain (1835 - 1910)]
Stephan Menzel
> Ich wußte es! ;)
Ich auch.
*Der* Thread *musste* "prOsT" werden.
> Aber so ist es, mal zum Testeen was hingeworfen und dann für ernsthafte
> Sachen angewöhnt.
Naja, aber manachmal liegt's auch am Methodendesign.
Im Fall, den ich eben noch schnell ausgebuegelt habe war als Return
einer Klasse ein Array angegeben. Ein Array von Packagedeklarationen
einer Klasse. Also wieviele Klassen laufen einem so ueber den Weg, die
in mehr als einem Package sind? Ich gehe also davon aus, dass ich den
ersten Fall will und schreibe also [0]. Kawumm! Exception beim Test
mit einer default-package-Klasse. Klarer Fall. Also schnell catch. Ich
weiss (jetzt!), es war boese und schlecht, aber wer gibt denn da auch
ein Array zurueck? Haette es nicht wenigstens eine List oder sowas
sein koennen? Naja, ich schiebe es mal auf die Performance.
BTW: ich hatte gerade den Eindruck, dass Freds bei denen das Wort
Exception im Subject steht und die nach 15 Uhr beginnen, die Tendenz
zum prost ausserordentlich stark ist. Google gibt mir da recht und die
Statistiken auf dclj.de ebenso. Wittere ich da ein neues dclj-Law?
Stephan, Entschuldigungen huestelnd
Stephan Menzel
> > Ihr habt recht! Ach Du schande, jetzt hab' ich mich als Coderschlampe
> ^^^^^^^^
> > geoutet.
>
>
> OK, "Carla" und ich nennen dich ab jetzt "Stephanie" ;-)
Arrrgggghhhh!
Das haengt mir jetzt wohl ewig nach.
> SCNR,
> Ingo, zeromultiplyer ;-)
ROTFL!
Das ist wenigstens noch definiert.
Stephan, den Zerodividerfred suchend
Michael Schmidt
> BTW: ich hatte gerade den Eindruck, dass Freds bei denen das Wort
> Exception im Subject steht und die nach 15 Uhr beginnen, die Tendenz
> zum prost ausserordentlich stark ist. Google gibt mir da recht und die
> Statistiken auf dclj.de ebenso. Wittere ich da ein neues dclj-Law?
>
Das sollte daran liegen, daß die Exception-Geschichte eigentlcih schon
nach drei Antworten ausgelutscht war und sich die Poster danach nur noch
dasselbe um die Ohren hauten.
Noch mehr liegt es aber dann daran, daß du eine Prost-Vorlage lieferst,
denn für diesen Thread haben Ingo und ich auf die gleiche Formulierung
reagiert und mehr Prost ist nicht gewesen. Du könntest aber insofern
Recht haben, daß sich Ingo R. nahezu auffällig in diesen eigentlich
schon erledigten Thread drängelte, als wartete er auf [Prost].
:)
Ingo Horn
>> SCNR,
>> Ingo, zeromultiplyer ;-)
>
> ROTFL!
> Das ist wenigstens noch definiert.
>
> Stephan, den Zerodividerfred suchend
http://groups.google.com/groups?q=durch+0+teilen+group:de.comp.lang.j
ava&hl=de&scoring=r&selm=3b306bd9%241%40netnews.web.de&rnum=2
Viel Spaß...
Goin, dem Feierabend entgegenstrebend
Stephan Menzel
> Das sollte daran liegen, daß die Exception-Geschichte eigentlcih schon
> nach drei Antworten ausgelutscht war und sich die Poster danach nur
> noch dasselbe um die Ohren hauten.
"hauten"? Gibt es das eigentlich?
Wie auch immer, mit irgendwas muss man ja seine Zeit verschwenden,
wenn die Proggerei unerwartet gut lief.
> Noch mehr liegt es aber dann daran, daß du eine Prost-Vorlage lieferst,
Irgendwer muss es doch tun!
> Du könntest aber insofern
> Recht haben, daß sich Ingo R. nahezu auffällig in diesen eigentlich
> schon erledigten Thread drängelte, als wartete er auf [Prost].
Tja, da haetten wir's!
Heute hat er so wenig gepostet, dass ich schon dachte, der Brueckentag
findet in B*e*e*e*d vor dem Feiertag statt und dabei lag er nur in den
Laberstartloechern. Alles klar! Und dann war ich es wieder...
Stephan, beschuldigend
Hendrick Kay
Bei Deinen Beispielen hast Du natürlich Recht, aber IllegalArgumentException
wird sehr wohl im Javacode erzeugt. (Sie war der Anlaß meines Beitrags)
Sie ist doch auch dazu gedacht um Parameter einer Methode auf Korrektheit zu
prüfen. Macht es hier nicht Sinn die Exception immer fangenzu müssen?
Eine Implementierung sollte IMHO immer mit falschen Eingaben zurechtkommen
und somit bin ich dafür, daß IllegalArgumentException keine RuntimeException
ist und somit immer gefangen werden muss.
Stimmen wir darüber ab? :)
Ciao
Hendrick
Ingo R. Homann
> .... Du könntest aber insofern
> Recht haben, daß sich Ingo R. nahezu auffällig in diesen eigentlich
> schon erledigten Thread drängelte, als wartete er auf [Prost].
WAS? Da liest man aufmerksam alle interessanten Threads des Tages mit,
findet nichts viel, worauf man antworten kann, geht für 10 Minuten in
die Cafete, kommt wieder und findet einen brandneuen, nach prOsT
geradezu schreienden Thread - noch dazu mit Postings, die *mehr als
fragwürdige Äußerungen* (auf die bis zu dem Zeitpunkt noch *niemand*
eingegangen war!) enthalten - vor, geht darauf ein, und dann wird einem
vorgeworfen, man würde sich in einen schon seit Monaten "erledigten
Thread drängeln" (was der ein oder andere^W^W^W Regular tatsächlich
manchmal tut)!?
;-)
Ciao,
Ingo
David Zerrenner
> Ehm, also da muss ich in der Tat mal belehren! ;-)
> Zur Compilezeit weiss man so gut wie nie, wo und warum eine Exception
> geworfen wird, das ist nicht nur bei RauntimeExceptions der Fall, denn
> *jede* Exception tritt zur Laufzeit auf. Insofern ist der Name
> "RuntimeException" vielleicht etwas ungeschickt gewählt (danke für den
> Hinweis, ist mir bisher noch gar nicht aufgefallen, hab' auch nie drüber
> nachgedacht!)
Stimmt schon, ich meinte jetzt Exceptions, die man selbst wirft.
Irgendwo habe ich mal gelesen, das es 'application exceptions'
und halt 'runtime exceptions' gibt oder so ähnlich. Eine genaue Quelle
habe ich leider nicht.
> Als "Hintertürchen" sehe ich es auch eher nicht, obwohl man es sicher
> als solches missbrauchen könnte.
Ok, ich habe es in einem anderen Posting von mir auch schon relativiert.
Ich hab da wohl doch zuwenig Ahnung von, bewege mich sozusagen auf
dünnem Eis.
> Alles andere ist glaube ich schon in diesem Thread (bzw. einem anderen
> Sub-Thread) gesagt worden, daher schließe ich mich dem Rest wortlos an.
> ;-)
wieder was gelernt :)
> Ciao,
> Ingo
tschö,
David
Martin Erren
"Hendrick Kay":
> Bei Deinen Beispielen hast Du natürlich Recht, aber IllegalArgumentException
> wird sehr wohl im Javacode erzeugt. (Sie war der Anlaß meines Beitrags)
Ja, das ist um eine RuntimeException quasi zu emulieren, und damit aussagekräftiger
zu machen.
> Sie ist doch auch dazu gedacht um Parameter einer Methode auf Korrektheit zu
> prüfen. Macht es hier nicht Sinn die Exception immer fangenzu müssen?
Nein, eben weil hier der Aufrufende was falsch gemacht hat, so wie:
void f(int n) {
if(n<0) throw new IllegalArgumentException(
"SM, bitte gewöhn' Dir die Codeschlamperei ab! "+
"Ich schrieb in der DOKU, f darf nur mit n>=0 aufgerufen werden, "
"nun ist n=" + n + " und das ist eindeutig unter 0!"
);
}
> Eine Implementierung sollte IMHO immer mit falschen Eingaben zurechtkommen
> und somit bin ich dafür, daß IllegalArgumentException keine RuntimeException
> ist und somit immer gefangen werden muss.
na, dann müsste ich z.B. zu oft auf null testen, und dann wäre der code nicht
mehr lesbar. Irgendwas muss man auch voraussetzen können.
> Stimmen wir darüber ab? :)
Ähh, seit <3CD93393...@bonelabs.com> sind wir nicht mehr demokratisch
organisiert...
Gruss: Martin
Calin Rus
Stephan Menzel wrote:
> [ArrayIndexOutOfBounds]
> Man balstelt an irgendwas rum, ploetzlich tritt bei einem Test sowas
> auf, man weiss warum und will es erstmal ignorieren, schnell gecatched
> und es bleibt drinnen. Ist unperformater, scheusslich zu lesen und
> allgemein verachtenswert aber was solls!
Genau, was solls...
Diesen fred hätte ich am liebsten heute mittag schon gelesen, als ich
mir nach 5 Stunden und der x-ten AIOOB-Exception am liebsten selbst in
den A... gebissen hätte. Nein, nicht mein code, sondern generierter!
Dabei hatte ich "bloß" vergessen, im deploytool den primary key für eine
simpelst-EJB mit CMP zu definieren. Ja, sowas wird mit Exceptions
bestarft, die nicht im Geringsten auf die Ursache deuten...
Gruß,
Calin, sich für's herumprosten entschuldigend
--
Die E-Mail-Adresse ist gültig!
Paul Ebermann
> Bei Deinen Beispielen hast Du natürlich Recht, aber IllegalArgumentException
> wird sehr wohl im Javacode erzeugt. (Sie war der Anlaß meines Beitrags)
> Sie ist doch auch dazu gedacht um Parameter einer Methode auf Korrektheit zu
> prüfen. Macht es hier nicht Sinn die Exception immer fangenzu müssen?
So in etwa?
---
String propValue = null;
try{
propValue = System.getProperty("");
}
catch(IllegalArgumentException ex) {
// Ich weiß, dass das Argument korrekt
// ist, also kann das nicht passieren.
}
---
Paul
Paul Ebermann
Christian Flügel wrote:
> > Runtime Exceptions sind solche Exceptions bei denen in der Regel das
> > Abfangen gar keinen Sinn macht. Zum Beispiel Division by Zero,
> > ArrayIndexOutOfBounds, NumberFormatException, Segmentation Fault etc.. Sie
> > werden nicht im Java Code sondern in der virtuelllen Maschine selbst
> > erzeugt.
> > Das Abfangen von solchen Exceptions ist zwar möglich, macht jedoch
> > eigentlich kaum Sinn da eine solche Exception auf einen Fehler hinweist bei
> > dem nur noch ein kompletter Abbruch des Programms sinnvoll ist. Deshalb
> > macht es auch keinen Sinn das RuntimeExceptions defaultmäßig vom
> > Programmierer gefangen werden müssen, stellt doch der Programmabbruch in den
> > meisten Fällen die beste oder einzig mögliche Lösung dar.
>
> Das ist jetzt nicht nachvollziehbar. Warum sollte das Programm
> abbrechen, wenn ich eine division durch 0 habe? Es kann doch sein, daß
> ich dann mit einem sinnvollen default-Wert weiterarbeiten kann. Es ist
> natürlich besser, diese Fehlerbedingung vorher abzufragen Bsp:
>
> if (c == 0) {
> a = b/c;
> } else {
> a = b/0.01;
> }
Nur so als Hinweis:
Eine ArithmeticException bei Division durch 0 gibt
es nur, wenn Ganzzahlarithmetik verwendet wird.
Bei Verwendung von double (wie dein Beispiel es
andeutet) kommt +-Unendlich oder NaN raus.
Paul
Hendrick Kay
Nunja, dein Parameter ist ziemlich konstant, da wäre es wohl übertrieben,
das gebe ich zu.
Ciao
Hendrick
Thomas Rachel
>> Offen gesagt bin ich auch noch nie auf die Idee gekommen (catch
>> RuntimeException) zu schreiben. Ausser jetzt natuerlich.
>
> Jein. IdR ist es nicht sinnvoll, da hast Du sicher recht. Aber
> wenn ich z.B. einen ServletServer schreibe, kann es schon ziemlich
> sinnvoll sein, daß ein kaputtes Servlet nicht gleich den ganzen
> Server abschießt, sondern daß der ServletServer diese Exception
> fängt und irgendwohin loggt, ggf. noch den offenen Request korrekt
> behandelt, etc...
Ich kenne mich mit ServletServern nicht so aus, aber laufen die nicht
jeder in einem eigenen Thread? Wenn ja, gibt es ja noch die Methode
ThreadGroup#uncaughtException(...), oder?
Thoma$
--
Das Leben ist wie eine Pralinenschachtel. Man weiss nie, was man kriegt.
(Forrest Gump)
Ingo R. Homann
>
> Ingo R. Homann:
>
> >> Offen gesagt bin ich auch noch nie auf die Idee gekommen (catch
> >> RuntimeException) zu schreiben. Ausser jetzt natuerlich.
> >
> > Jein. IdR ist es nicht sinnvoll, da hast Du sicher recht. Aber
> > wenn ich z.B. einen ServletServer schreibe, kann es schon ziemlich
> > sinnvoll sein, daß ein kaputtes Servlet nicht gleich den ganzen
> > Server abschießt, sondern daß der ServletServer diese Exception
> > fängt und irgendwohin loggt, ggf. noch den offenen Request korrekt
> > behandelt, etc...
>
> Ich kenne mich mit ServletServern nicht so aus, aber laufen die nicht
> jeder in einem eigenen Thread? Wenn ja, gibt es ja noch die Methode
> ThreadGroup#uncaughtException(...), oder?
IIRC gibt es die "Since 1.3" oder so, ja. Mein tomcat läuft aber AFAIK
unter JDK1.2.2.
Anyway, irgendwie muß das ganze ja gehandhabt werden, und ich kann mir
nicht vorstellen, daß der uncaughtException-Handler intern wesentlich
anders implementiert ist als etwa so:
...
try {
thread.run();
} catch(Throwable t) {
threadGroup.uncaughtException(t);
}
...
...wobei letztendlich also auch RuntimeExceptions gefangen werden. qed.
Leider habe ich die 1.3er-Sourcen gerade nicht da, um das zu
verifizieren, aber wie gesagt, so oder ähnlich *muß* es ja schließlioch
gehen...
Ciao,
Ingo
Christian Wederhake
> String propValue = null;
> try{
> propValue = System.getProperty("");
> }
> catch(IllegalArgumentException ex) {
> // Ich weiß, dass das Argument korrekt
> // ist, also kann das nicht passieren.
> }
Seit 1.4 habe ich saemtlichen code, in dem ich deartiges noch
stehen hatte mit assertions versuesst...
Ciao
Chris
--
"Insbesondere nach den Einblicken in 'Darla'? Was haben die denn
erwartet? Dass Angel ihr um den Hals fällt, die letzten 110 Jahre
vergisst und er sich eben einen Tropfen of true happiness rausquetscht
und zu Angelus morpht?" (Stefan Rauter über W&H [de.rec.tv.buffy])
Thomas Rachel
>> Ich kenne mich mit ServletServern nicht so aus, aber laufen die
>> nicht jeder in einem eigenen Thread? Wenn ja, gibt es ja noch die
>> Methode ThreadGroup#uncaughtException(...), oder?
>
> IIRC gibt es die "Since 1.3" oder so, ja. Mein tomcat läuft aber
> AFAIK unter JDK1.2.2.
* @since JDK1.0
> Anyway, irgendwie muß das ganze ja gehandhabt werden, und ich kann
> mir nicht vorstellen, daß der uncaughtException-Handler intern
> wesentlich anders implementiert ist als etwa so:
>
[snip]
Kann sein, aber das muß schon eine Ebene weiter oben sein. Die Doku
schreibt dazu:
/**
* Called by the Java Virtual Machine when a thread in this
* thread group stops because of an uncaught exception.
* <p>
[...]
> Leider habe ich die 1.3er-Sourcen gerade nicht da, um das zu
> verifizieren, aber wie gesagt, so oder ähnlich *muß* es ja
> schließlioch gehen...
public void uncaughtException(Thread t, Throwable e) {
if (parent != null) {
parent.uncaughtException(t, e);
} else if (!(e instanceof ThreadDeath)) {
e.printStackTrace(System.err);
}
}
Wie gesagt, das Aufrufen dieser Methode geschieht irgendwie durch die
VM. Liegt wohl irgendwo zwischen Thread#start, Thread#run und dem hier
begraben... start ist ja native implemetiert (muß ja), und vermutlich
wird es dort irgendwo gehandlet. Läuft aber im Endeffekt auf das von
Dir Beschriebene hinaus. Man muß es aber dann nicht mehr selbst tun,
was eleganter ist...
Thoma$
--
Wenn Dich im Usenet einer einen Esel nennt, lach ihn aus. Wenn es viele
tun, die ansonsten ganz vernünftige Beiträge schreiben, dann schau Dich
schon einmal nach einer Wiese mit saftigem Gras um.
(Christian Pree zu Robert Hanke in de.alt.admin)
Paul Ebermann
Was ich illustrieren wollte:
In diesem Fall irrt der Programmierer, denn das Argument
ist eben _nicht_ korrekt. Und da man die Exception fängt,
fällt das nicht mehr auf, also gibt es später an
irgendeiner anderen Stelle eine nicht-nachvollziehbare
NullpointerException.
Paul
Ingo R. Homann
>
> Ingo R. Homann:
>
> >> Ich kenne mich mit ServletServern nicht so aus, aber laufen die
> >> nicht jeder in einem eigenen Thread? Wenn ja, gibt es ja noch die
> >> Methode ThreadGroup#uncaughtException(...), oder?
> >
> > IIRC gibt es die "Since 1.3" oder so, ja. Mein tomcat läuft aber
> > AFAIK unter JDK1.2.2.
>
> * @since JDK1.0
Argl! Muss das wohl mit ähnlicher Exception-Handling-Methode verwechselt
haben, die es bei AWT oder Swing gibt (und da IIRC *wirklich* nicht ab
JDK1.0)
Ciao,
Ingo
Uwe Plonus
> "Uwe Plonus" skribis:
>>
>>if (c == 0) {
>> a = b/c;
>>} else {
>> a = b/0.01;
>>}
>>
>
> Nur so als Hinweis:
> Eine ArithmeticException bei Division durch 0 gibt
> es nur, wenn Ganzzahlarithmetik verwendet wird.
> Bei Verwendung von double (wie dein Beispiel es
> andeutet) kommt +-Unendlich oder NaN raus.
Es war als Beispiel gedacht...
Uwe
Uwe Plonus
> Uwe Plonus schrieb:
>
>>> Belehrt mich, wenn ich falsch liege, aber ich glaube, da hält man sich
>>> ein Hintertürchen offen. Bei unserem EJB-Container z.B. darf man die gar
>>> nicht selber werfen, weil der Server dann den Löffel abgibt, sprich, er
>>> fängt die RuntimeException selbst und beendet sich dann. In der Doku
>>> stand dazu, dass man es halt vermeiden sollte, RuntimeExceptions zu
>>> werfen.
>>
>>
>> Ich weiß nicht, was Du mit Hintertürchen meinst...
>
>
> Naja, abgesehen von den Gründen, die in den anderen Postings stehen,
> meine ich mit Hintertürchen eben z.B. den Fall, dass wirklich was
> schlimmes passiert (Segmentation Fault etc.). Was machst Du dagegen?
> In dem Fall wird eine Exception geworfen, aber du kannst nie
> vorhersehen, wo.
>
> Vielleicht auch für den Fall, dass dein Code innerhalb irgendeiner
> Engine läuft (EJB-Conteiner, Servlets, etc.). Da können die Container
> diese Exceptions fangen.
Du sprichst hier von Errors, die auch nicht abgefangen werden müssen.
Das ist etwas anderes als RuntimeExceptions.
Uwe
Uwe Plonus
>
>> if (c == 0) {
>> a = b/c;
>> } else {
>> a = b/0.01;
>> }
>
>
>
>
> äh... meinst du es so?
>
> if (c != 0)
> a = b/c;
> else
> a = b/0.01;
Ja...
Wieder schneller geschrieben als gedacht ;)
Uwe
David Zerrenner
>> Vielleicht auch für den Fall, dass dein Code innerhalb irgendeiner
>> Engine läuft (EJB-Conteiner, Servlets, etc.). Da können die Container
>> diese Exceptions fangen.
>
> Du sprichst hier von Errors, die auch nicht abgefangen werden müssen.
> Das ist etwas anderes als RuntimeExceptions.
Nicht ausschliesslich, habe ich auch schon aus eigener Erfahrung erlebt,
und die Spec spricht auch ausdrücklich von RuntimeException /or/ Errors:
| The enterprise bean business method and container callback methods may
| encounter various exceptions or errors that prevent the method from
| successfully completing. Typically, this happens because the
| exception or error is unexpected, or the exception is expected but the
| EJB Provider does not know how to recover from it. Examples of such
| exceptions and errors are: failure to obtain a database connection,
| JNDI API exceptions, unexpected RemoteException from invocation of
| other enterprise beans[14], unexpected RuntimeException, JVM errors,
| and so on.
Quelle: Enterprise JavaBeans(TM) Specification, v1.1, Kapitel 12.2.2
tschö,
David