Checked Exceptions

[volkard]

MBCS-CITP schrieb:

Wobei wir damit dem Grund haben, jede Allocierung von Speicher (schliesslich macht dies jeder new-Operator) abzufangen als try-catch. Das ist zwar Arbeit, aber es hilft.

hä?

[7H3 N4C3R]

@volkard:

@MBCS-CITP:
so in etwa?:

void test()
{
  try {
    int i = 5;
    try {
       int j = 6;
       try {
         printf( "5 + 6 = %i", i+j);
       }
       catch(const bad_alloc&) {
         printf( "kein Speicher für temporäres i+j");
       }
    }
    catch(const bad_alloc&) {
       printf( "kein Speicher für j");
    }
  }
  catch(const bad_alloc&) {
    printf( "kein Speicher für i");
  }
}

Ich hoffe, das ist nicht dein Ernst Und was bringt es Dir, das abzufangen? Wozu gibt es Objekte mit automatic storage und was bringt RIAA? Warum wurden Exceptions eingeführt, wenn man sie sofort wieder catchen will? Und was sind die Nachteile von Returncodes?

Bevor jemand meckert: Jede Optimierung und Sinnlosigkeit sei vernachlässigt

[Bashar]

MBCS-CITP schrieb:

Wobei wir damit dem Grund haben, jede Allocierung von Speicher (schliesslich macht dies jeder new-Operator) abzufangen als try-catch. Das ist zwar Arbeit, aber es hilft.

Das ist eigentlich kaum Arbeit. Man kann das ja schon mit einem try..catch in der main erreichen. Oder an einer anderen Stelle, an der man sinnvoll auf diese Exception reagieren kann.

[MBCS-CITP]

Du hast dann zwar ein Mssg., dass z. B. ein Constructor eine Exception wirft, aber weisst immer noch nicht in welchen Zusammenhang. Wenn Du von einer Klasse viele Instanzen an unterschiedlichen Orten creierst, so hilft das wenig bei der Fehlersuche.

[volkard]

MBCS-CITP schrieb:

Du hast dann zwar ein Mssg., dass z. B. ein Constructor eine Exception wirft, aber weisst immer noch nicht in welchen Zusammenhang. Wenn Du von einer Klasse viele Instanzen an unterschiedlichen Orten creierst, so hilft das wenig bei der Fehlersuche.

hast du keinen debugger?

[MBCS-CITP]

volkard schrieb:

hast du keinen debugger?

Das Problem ist bei nicht zu allocierenden Speicher, dass dies oft bei der Debugg-Version nicht auftritt, sehr wohl aber bei der optimierten Version (hatte auch schon entsprechende Probleme mit dem Stack). Diese enthaelt aber keine Debug-Informationen mehr. D. h. selbst das prozierte Schreiben eines Core-Files nutzt nicht mehr viel.

[7H3 N4C3R]

Was interessiert es denn, wo man keinen Speicher mehr bekommen hat? Wenn man eh keinen Speicher mehr bekommt, kann man doch sowieso nur noch die weiße Fahne schwenken. Und zwar am besten an irgendeiner zentralen Stelle. Übrigens mit der Hoffnung, dass durch automatisches Abräumen bis dahin schon wieder n bissl Speicher frei geworden ist.

[MBCS-CITP]

7H3 N4C3R schrieb:

Was interessiert es denn, wo man keinen Speicher mehr bekommen hat? Wenn man eh keinen Speicher mehr bekommt, kann man doch sowieso nur noch die weiße Fahne schwenken. Und zwar am besten an irgendeiner zentralen Stelle.

Dann beginnt erst die Arbeit. Man muss dann einen Heapwalk machen, um zu sehen, wie der Speicher eigentlich aussieht. Wenn es z. B. an einer zu starken Fragnmentierung lag (sollte kein Problem mehr sein, die Prozessoren sind schon recht clever), muss man groesse Blocke Heap mit einem Schwung allocieren oder, so moeglich, zum Beginn des Programmes den max. benoetigen Haep berechnenen und dann allocieren. In Falle von Stack-Overflow muss man sehen, wie man Variablen in den Stack schiebt und z. B. Referenze-Uebergaben durch Pointer ersetzen, Klassen nicht als locale Variable in den Stack schreiben, sondern innerhalb des Blockes eine neue Instanz mittels des new-Operators in den Haep schreiben und dann wieder loeschen. Man muss sich dann auch anschauen, wie man notwendige Recursionen stack-optimiert.

[7H3 N4C3R]

Und dann ist der Heap voll... und dann?

Schreibst Du dir einen eigenen Allocator, dass Du weißt, wie dein Speicher aussieht?

Ich glaube, wenn man alle Ressourcen verbrezelt hat, sollte man sich eher mal ein paar Gedanken über seine Algorithmen machen.

[MBCS-CITP]

7H3 N4C3R schrieb:

Ich glaube, wenn man alle Ressourcen verbrezelt hat, sollte man sich eher mal ein paar Gedanken über seine Algorithmen machen.

Nicht unbedingt - es kann z. B. eine Amok laufende Recursion sein, bei der ein Typo in der Abbruchbedingung diese sehr viel mehr Speicher allocieren laesst, als notwendig. Es kann auch sein, dass Datentypen zu aufgeblaeht sind (Daten doppelt und dreifach, statt mit referenzen oder Zeigern zu den Daten zu arbeiten). Die Moeglichkeiten sind viele und dort kann eigentlich nur eine Analyse des Heaps weiterhelfen.

[7H3 N4C3R]

Sowas sind doch aber Entwicklungsfehler/-probleme, und nichts was mal der Kunde zu spüren bekommt. Sowas bekommst du mit Debugger und ein paar nützlichen Tools wesentlich besser hin. Und so einen Entwicklungsaufwand kann man wohl nur schwer rechtfertigen. Außerdem eröffnest Du dir so Optimierungspotenzial für eine Version 2.0