.NET (1.1) - IOException unterscheiden

[renew]

Ich habe folgendes Problem in .NET:
ich möchte ein File auf die Platte schreiben und dabei die unterschiedlichen Exceptions abfangen.

Jetzt bekomme ich aber eine IOException wenn die Festplatte voll ist, als auch wenn das File was ich schreiben möchte gerade geöffnet ist.
Nur ex.Message ist unterschiedlich (is ja logisch).

Einen Sting-Vergleich auf ex.message zu machen, um diese beiden Fälle zu unterscheiden ist sehr unsauber, da die message auf einem engl. System ja anders lauten wird.
Nur finde ich beim IOException Objekt auch keine "ID" od. ähnliches wodurch ich solche Unterschiede abfragen könnte.

Gibt es da eine Möglichkeit solche "Unterpunkte" abzufangen - weil es gibt ja auch keine erbende Klasse von IOException die sich mit dem Problem befasst....

herzlichen Dank, mfg renew

[Biri]

hi,

ohne das jetzt näher angeschaut oder getestet zu haben, ich glaub, hier steht etwas zu einem problem: http://www.msdner.com/dev-archive/6/12-39-67117.shtm

fg
hannes

[renew]

Hi, herzlichen Dank. Im Prinzip wäre das genau das was ich mir wünsche.
Funkt nur leider nicht (gerade getestet).
Bei mir kommt bei Err.Number 57 - bei File gerade geöffnet als auch bei Disk Full (mit Disk-Quotas simuliert).

Blöde Geschichte...

Und was auch noch spannend wird (falls ich es zum Laufen bekomme) ob die Err.Numbers unter XP die gleichen sind wie unter 2003 Server.
Weil derzeit wird unter XP entwickelt, wird aber im Echt-System auf 2003 Server laufen, bzw. in weiterer Folge unter XP für andere Anwendungen zur Entwicklungszeit als "Library" verwendet.... (die dann auf den 2003 Server deployed werden...)

[Biri]

hi,

ein anderer Ansatz wäre natürlich, das gesammte Execption Konzept zu überdenken. Exception = etwas "Unerwartetes".

Man könnte also, wenn möglich, zuvor gewisse Prüfungen einbauen - Exceptions die man nicht handlen kann, sollte man sowieso weiterreichen - gerade, WENN du eine Library schreibst, die von anderen verwendet wird, sollte man das so machen.

Derjenige, welcher die Library verwendet, muss halt dann entscheiden, wie er mit der Exception umgeht - das ist nicht Aufgabe der Library, denn diese kann ja garnicht wissen, was passieren sollen, wenn Exceptions auftreten.

fg
hannes

[renew]

Grundsätzlich natürlich richtig.

Wobei die "verwendende" Anwendung altes ASP ist und meine Klasse daher per COM aufgerufen wird.
Und Fehlerbehandlung in VB (6.0) ist, ähhm, bescheiden.
Daher liefert meine Library nur einen Return-Code (was jetzt passiert ist) und fängt daher schon alle Exceptions ab.
Denn auch die Err-Number bei Fehlerbehandlung per VB6-Code (on error goto) ist nicht brauchbar - da das irgendwelche Nummern sind, das habe ich auch schon ausprobiert.

Aber ich hab beschlossen, dass er einfach damit leben muss, es sind sowieso nur 2 Fälle die man unterscheiden muss. Entweder is die Disk voll (das wird wohl nicht oft vorkommen) od. das File is gerade geöffnet....