Prozedur und Funktion

[volkard]

Du findest auch global failing gut. hihihi.
Das spricht eher gegen checked exceptions, als dafür.

[audacia]

DEvent schrieb:

Checked Exceptions sind in Java schon auf Dauer

Ja, loswerden kann man die wohl nicht mehr, nur noch totschweigen und möglichst nicht benutzen. (Genau wie export template in C++.)

DEvent schrieb:

ich finde die Idee der checked exceptions gut

Ich finde die Idee des Kommunismus auch gut.

DEvent schrieb:

Z schrieb:

Für jemanden, der den Funktionsbegriff aus dem Mathematikunterricht kennt, kann das, was in C++ als Funktion bezeichnet wird, auf den ersten Blick irreführend sein.

Wie das?

In den meisten Programmiersprachen mit prozeduralen Wurzeln können Funktionen Nebeneffekte haben. Der Funktionsbegriff der Mathematik hat aber überhaupt nichts mit Anweisungen, Auswirkungen, Effekten zu tun; eine Funktion tut nichts, sie ist nur eine Abbildung aus einer Menge in eine andere.

[DEvent]

audacia schrieb:

DEvent schrieb:

Checked Exceptions sind in Java schon auf Dauer

Ja, loswerden kann man die wohl nicht mehr, nur noch totschweigen und möglichst nicht benutzen. (Genau wie export template in C++.)

DEvent schrieb:

ich finde die Idee der checked exceptions gut

Ich finde die Idee des Kommunismus auch gut.

Ich finde es besser zu wissen, welche Exceptions eine Methode werfen kann und welche ich fangen sollte. Besser als in C++/C# wo eine Methode alles werfen kann. Da die Dokumentation nicht immer aktuell ist, ist es besser dass es der Compiler für mich Überprüfen kann.

Wieso sollte man die totschweigen und nicht benutzen? Besser als dann das Programm sich beendet, weil man eine Exception vergessen hat zu fangen, oder ein Programm läuft weiter, weil man eine Exception zu viel gefangen hat.

Wie kann man eigentlich const-correctnes von C++ gut finden, aber Checked Excpetions schlecht?

[volkard]

DEvent schrieb:

Wie kann man eigentlich const-correctnes von C++ gut finden, aber Checked Excpetions schlecht?

Zum Beispiel "Ein anderer Einwand ist, dass aufgrund der Deklaration der Exceptions in den Methodensignaturen allgemein verwendbare Hilfsklassen oder Interfaces, insbesondere als Teil von Entwurfsmustern, oft nicht sinnvoll operabel sind mit Klassen, die Checked Exceptions verwenden." http://de.wikipedia.org/wiki/Ausnahmebehandlung#Checked_Exceptions

[audacia]

DEvent schrieb:

Ich finde es besser zu wissen, welche Exceptions eine Methode werfen kann und welche ich fangen sollte. Besser als in C++/C# wo eine Methode alles werfen kann. Da die Dokumentation nicht immer aktuell ist, ist es besser dass es der Compiler für mich Überprüfen kann.

Wieso sollte man die totschweigen und nicht benutzen?

Ach komm, die Diskussion wurde so oft geführt, das muß jetzt nicht auch noch hier sein. Wenn du wirklich über das Für und Wider zu Checked Exceptions streiten willst, mache bitte einen neuen Thread auf.

DEvent schrieb:

Besser als dann das Programm sich beendet, weil man eine Exception vergessen hat zu fangen

Wieso sollte es sich dann beenden Zumindest meine Programme haben in der Message-Pump einen unkonditionellen Exception-Handler. Wenn eine unerwartete Exception fliegt, wird die aktuelle Operation abgebrochen, ggf. ein Dialog für das Senden eines Bug-Reports angezeigt, und dann kanns weitergehen.

DEvent schrieb:

Wie kann man eigentlich const-correctnes von C++ gut finden, aber Checked Excpetions schlecht?

Ganz hervorragende Frage für einen neuen Thread.

[µngbd]

Z schrieb:

Für jemanden, der den Funktionsbegriff aus dem Mathematikunterricht kennt, kann das, was in C++ als Funktion bezeichnet wird, auf den ersten Blick irreführend sein.

Das dürfte der Grund sein, warum zumindest eine Sprache (Scheme) alle diese Dinger pauschal "procedures" nennt.

Gerade fällt mir wieder ein, dass ich in der Schule mit Visual Basic gefoltert wurde, wo man manchmal Klammern um die Argumente machen muss (wenn man den Wert verwendet) und manchmal nicht (wenn nicht). Wahnsinn, sowas. Ist das noch so?

[uio]

audacia schrieb:

DEvent schrieb:

Besser als dann das Programm sich beendet, weil man eine Exception vergessen hat zu fangen

Wieso sollte es sich dann beenden Zumindest meine Programme haben in der Message-Pump einen unkonditionellen Exception-Handler. Wenn eine unerwartete Exception fliegt, wird die aktuelle Operation abgebrochen, ggf. ein Dialog für das Senden eines Bug-Reports angezeigt, und dann kanns weitergehen.

Das ist ja mal richtig undefiniert und gefährlich.

[audacia]

uio schrieb:

audacia schrieb:

Wieso sollte es sich dann beenden Zumindest meine Programme haben in der Message-Pump einen unkonditionellen Exception-Handler. Wenn eine unerwartete Exception fliegt, wird die aktuelle Operation abgebrochen, ggf. ein Dialog für das Senden eines Bug-Reports angezeigt, und dann kanns weitergehen.

Das ist ja mal richtig undefiniert und gefährlich.

Weil?

[uio]

audacia schrieb:

uio schrieb:

audacia schrieb:

Wieso sollte es sich dann beenden Zumindest meine Programme haben in der Message-Pump einen unkonditionellen Exception-Handler. Wenn eine unerwartete Exception fliegt, wird die aktuelle Operation abgebrochen, ggf. ein Dialog für das Senden eines Bug-Reports angezeigt, und dann kanns weitergehen.

Das ist ja mal richtig undefiniert und gefährlich.

Weil?

Woher weißt du was noch funktioniert, wenn eine unerwartete Exception geflogen ist?

[audacia]

uio schrieb:

Woher weißt du was noch funktioniert, wenn eine unerwartete Exception geflogen ist?

Exceptions sind meistens unerwartet, deshalb heißen sie so. Wenn das Programm exceptionsicher ist, passiert auch nichts schlimmes. (Wenn du anderer Meinung bist, bemühe bitte ein Gegenbeispiel.)
Wenn ich eine unerwartete Zugriffsverletzung abfange, mag dein Einwand in der Theorie berechtigt sein, aber auch da sind die Folgen meist harmlos genug, daß man den Nutzer wenigstens noch abspeichern lassen kann.

[uio]

audacia schrieb:

uio schrieb:

Woher weißt du was noch funktioniert, wenn eine unerwartete Exception geflogen ist?

Exceptions sind meistens unerwartet, deshalb heißen sie so. Wenn das Programm exceptionsicher ist, passiert auch nichts schlimmes.

Nö. Eine Exception ist eine Ausnahme die bei bestimmten Operationen passieren kann. Netzwerkverbindung bricht ab usw. Eine unerwartete Exception resultiert aus einem Programmierfehler. Child hat plötzlich keine Parents mehr oder sowas. Die Wahrscheinlichkeit, dass du ein Programm hast, bei dem alles exceptionsicher ist, aber unerwartete Exceptions auftreten ist sehr gering.

Wenn ich eine unerwartete Zugriffsverletzung abfange, mag dein Einwand in der Theorie berechtigt sein, aber auch da sind die Folgen meist harmlos genug, daß man den Nutzer wenigstens noch abspeichern lassen kann.

wenigstens noch abspeichern und und dann kanns weitergehen ist mal ein ganz schön großer Unterschied.

[audacia]

uio schrieb:

wenigstens noch abspeichern und und dann kanns weitergehen ist mal ein ganz schön großer Unterschied.

Unerwartete Exception und unerwartete Zugriffsverletzung ist auch ein ganz schön großer Unterschied, den du geflissentlich ignorierst.

Appendix: Um das noch etwas deutlicher zu machen: ich sagte in bezug auf Sprachexceptions "dann kanns weitergehen", und dazu stehe ich. Nach Sprachexceptions beliebiger Art und Abstammung bleiben meine Anwendungen stabil.

[volkard]

audacia schrieb:

uio schrieb:

wenigstens noch abspeichern und und dann kanns weitergehen ist mal ein ganz schön großer Unterschied.

Unerwartete Exception und unerwartete Zugriffsverletzung ist auch ein ganz schön großer Unterschied, den du geflissentlich ignorierst.

Appendix: Um das noch etwas deutlicher zu machen: ich sagte in bezug auf Sprachexceptions "dann kanns weitergehen", und dazu stehe ich. Nach Sprachexceptions beliebiger Art und Abstammung bleiben meine Anwendungen stabil.

Stabil ist aber zu unter Umständen viel zu wenig. Ist es korrekt? Was aber nicht am Fangen und Ignorieren unerwarteter Fehler liegt, sondern weil Du in kritischen Pfaden keine Fehler produzierst. Zum Beispiel muß bei der Ausbuchung des Buchs auch das Geld dafür eingebucht werden. Geht beim Einbuchen was schief, weil der Benutzer ein 'ß' in der Adresse hat, fliegt die Exception, Du fängst sie und machst mal locker weiter. Kunde freut sich natürlich.
Da muß man erstmal drauf kommen!
Aber ich glaube, das geht nur in Problemstellungen, für die Java ursprünglich gedacht ist, Steuercode für Waschmaschinen und Toaster.

[audacia]

volkard schrieb:

Zum Beispiel muß bei der Ausbuchung des Buchs auch das Geld dafür eingebucht werden. Geht beim Einbuchen was schief, weil der Benutzer ein 'ß' in der Adresse hat, fliegt die Exception, Du fängst sie und machst mal locker weiter. Kunde freut sich natürlich.

Das ist ein Transaktionsproblem und muß natürlich entsprechend gesondert behandelt werden. Es hat aber, wie du selbst feststellst, nicht viel damit zu tun, ob ich bei unerwarteten Exceptions die Anwendung terminiere oder weiterlaufen lasse; die Datenbank ist in beiden Fällen inkonsistent, wenn ich nicht richtig vorsorge.

[volkard]

Also bei der Lektüre von

try {
    //Berechne ...
} catch (OutOfMemoryError e) {
    //Ein Error ist keine Exception und muss separat abgefangen werden
    e.printStackTrace();
} catch (RuntimeException e) {
    //z.B. IndexOutOfBoundsException, NullPointerException usw.
    System.err.println("Offensichtlich ein Programmierfehler!");
    throw e; //Leite nach oben weiter
} catch (Exception e) {
    //Fange alle restlichen Ausnahmefehler ab
    e.printStackTrace();      
} catch (Throwable t) {
    //Das hier fängt wirklich alles ab
    t.printStackTrace();
} finally {
    //Ob Exception oder nicht, führe das hier auf jeden Fall aus.
    System.out.println("Berechnung beendet oder abgebrochen");
}

mußte ich erstmal herzlich lachen.

[geben Sie einen Benutzern]

volkard schrieb:

audacia schrieb:

uio schrieb:

wenigstens noch abspeichern und und dann kanns weitergehen ist mal ein ganz schön großer Unterschied.

Unerwartete Exception und unerwartete Zugriffsverletzung ist auch ein ganz schön großer Unterschied, den du geflissentlich ignorierst.

Appendix: Um das noch etwas deutlicher zu machen: ich sagte in bezug auf Sprachexceptions "dann kanns weitergehen", und dazu stehe ich. Nach Sprachexceptions beliebiger Art und Abstammung bleiben meine Anwendungen stabil.

Stabil ist aber zu unter Umständen viel zu wenig. Ist es korrekt? Was aber nicht am Fangen und Ignorieren unerwarteter Fehler liegt, sondern weil Du in kritischen Pfaden keine Fehler produzierst. Zum Beispiel muß bei der Ausbuchung des Buchs auch das Geld dafür eingebucht werden. Geht beim Einbuchen was schief, weil der Benutzer ein 'ß' in der Adresse hat, fliegt die Exception, Du fängst sie und machst mal locker weiter. Kunde freut sich natürlich.
Da muß man erstmal drauf kommen!
Aber ich glaube, das geht nur in Problemstellungen, für die Java ursprünglich gedacht ist, Steuercode für Waschmaschinen und Toaster.

Mit C++ fstreams geht das aber viel einfacher.

int main()
{
	std::ofstream f("xy:z::dsa");
	f<<"ssfdad";
	std::cout<<"Fertig";
}

Da fliegt keine Exception die man falsch fangen kann. Das Programm läuft einfach durch und der Kunde freut sich.

Das Problem an den Checked-Exceptions von Java ist einfach, dass sie sie viel zu oft verwenden und dass jeder Wirtschaftsinformatiker mit Java rum hackt.

volkard schrieb:

Also bei der Lektüre von

try {
    //Berechne ...
} catch (OutOfMemoryError e) {
    //Ein Error ist keine Exception und muss separat abgefangen werden
    e.printStackTrace();
} catch (RuntimeException e) {
    //z.B. IndexOutOfBoundsException, NullPointerException usw.
    System.err.println("Offensichtlich ein Programmierfehler!");
    throw e; //Leite nach oben weiter
} catch (Exception e) {
    //Fange alle restlichen Ausnahmefehler ab
    e.printStackTrace();      
} catch (Throwable t) {
    //Das hier fängt wirklich alles ab
    t.printStackTrace();
} finally {
    //Ob Exception oder nicht, führe das hier auf jeden Fall aus.
    System.out.println("Berechnung beendet oder abgebrochen");
}

mußte ich erstmal herzlich lachen.

Wer hat das geschrieben?

[SideWinder]

Das hat irgendein Spaßvogel in die Wikipedia eingetragen.

MfG SideWinder

[Black Sun]

geben Sie einen Benutzern schrieb:

Mit C++ fstreams geht das aber viel einfacher.

int main()
{
	std::ofstream f("xy:z::dsa");
	f<<"ssfdad";
	std::cout<<"Fertig";
}

Da fliegt keine Exception die man falsch fangen kann. Das Programm läuft einfach durch und der Kunde freut sich.

Davon abgesehen, dass niemand für dieses Programm Geld bezahlen würde,
Was passiert, wenn die datei nicht geöffnet werden kann? Nichts?

[geben Sie einen Benutzern]

Genau darum ging es. Wenn du alles gelesen hättest, wüstest du das jetzt die Rechnung nicht gespeichert wurde.

[DEvent]

volkard schrieb:

Also bei der Lektüre von

try {
    //Berechne ...
} catch (OutOfMemoryError e) {
    //Ein Error ist keine Exception und muss separat abgefangen werden
    e.printStackTrace();
} catch (RuntimeException e) {
    //z.B. IndexOutOfBoundsException, NullPointerException usw.
    System.err.println("Offensichtlich ein Programmierfehler!");
    throw e; //Leite nach oben weiter
} catch (Exception e) {
    //Fange alle restlichen Ausnahmefehler ab
    e.printStackTrace();      
} catch (Throwable t) {
    //Das hier fängt wirklich alles ab
    t.printStackTrace();
} finally {
    //Ob Exception oder nicht, führe das hier auf jeden Fall aus.
    System.out.println("Berechnung beendet oder abgebrochen");
}

mußte ich erstmal herzlich lachen.

Das ist ja auch grundlegend Falsch.
Mein Code sieht meistens so aus:

public void doSomething() throws MyException {
  try {
      doSomething0();
  } catch (IOException e) {
    throw new MyException(e);
  } catch (SQLException e) {
    throw new MyException(e);
  } catch ...
  finally {
  }
}

private void doSomething0()  throws IOException, SQLException, .... {
  // do some stuff
}

Aber das Java's checked exceptions were a mistake (and here's what I would like to do about it)
Sehe ich ein, dass Checked Exceptions bei "Zwischen APIs" Probleme machen.