Prozedur und Funktion

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.

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

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?

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.

Shade Of Mine

DEvent schrieb:

Mein Code sieht meistens so aus:

und da ist dir noch nie in den sinn gekommen dass das ein bisschen schwachsinnig ist?

Gibts eigentlich nichts besseres zur Fehlerbehandlung? Entweder man muss überall hinschreiben was es für Exceptions gibt oder man weiß nicht welche es geben kann. Ist doch beides Müll.

Dravere

17° schrieb:

Gibts eigentlich nichts besseres zur Fehlerbehandlung? Entweder man muss überall hinschreiben was es für Exceptions gibt oder man weiß nicht welche es geben kann. Ist doch beides Müll.

Gibt Programme, welche den Callstack im Code analysieren und entsprechend Warnungen ausgeben können, falls irgendwo in einer Richtung eine Exception nicht gefangen wurde.

Am besten sollte dies gleich der Kompiler machen.

Und wieso gibt es nun den Unterschied zwischen Prozedur und Funktion?

Grüssli

Shade Of Mine

17° schrieb:

oder man weiß nicht welche es geben kann

Dafür gibt es die Doku.

Tachyon

In Sprachen wie Ada gehört der Rückgabewert einer Funktion zur Funktionssignatur. Dementsprechend kann man eine Funktion auch für unterschiedliche Rückgabewerte aber gleiche Parameterlisten überladen. Dafür darf allerdings der Rückgabewert auch nicht ignoriert werden, weil dann Mehrdeutigkeiten entstehen würden.

DEvent

Shade Of Mine schrieb:

DEvent schrieb:

Mein Code sieht meistens so aus:

und da ist dir noch nie in den sinn gekommen dass das ein bisschen schwachsinnig ist?

Sind wir hier bei Twitter?

Shade Of Mine schrieb:

17° schrieb:

oder man weiß nicht welche es geben kann

Dafür gibt es die Doku.

Als ob die Doku irgendein Anspruch auf Aktualität hält.
Wenn die Doku doch genügt, wieso dann die const-correctnes von C++? Es reicht doch wenn ich in die Doku schreibe "Die Methode verändert den Zustand des Objektes nicht".

Shade Of Mine schrieb:

17° schrieb:

oder man weiß nicht welche es geben kann

Dafür gibt es die Doku.

Das gleiche Problem wie bei checked Exceptions. Schreibst du alle Exceptions rein die alle "Sub-Funktionen" werfen könnten oder nur die, die die Funktion direkt wirft, dann hast du wieder nicht alle? Was machst du mit sowas wie boost::signal? Da kann alles mögliche dahinter sein.

[quote="DEvent"
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 {
  }
}

[/quote]
Ich habe zwar keine Ahnung von Java und finde es auch ziemlich doof :p
Aber wars nicht so, dass alle Exceptions von "Exception" abgeleitet sind, so dass Du es so machen kannst?

public void doSomething() throws MyException {
  try 
  {
    doSomething0();
  } 
  catch (Exception e)  // fängt alle Exceptions 
  {
    throw new MyException(e);
  }
}

Ja, kannst du. Dass DEvent kein Java kann hat er ja schon zu genüge in anderen Threads bewiesen

Vielleicht will er ja nicht alles fangen