Zitat von cosmochaosmaker

@Fehlercodes:
Wieso sollte die Funktion Angaben zum Fehler machen?
Stell Dir vor Du arbeitest mit einem DAL. Und es gibt eine DB-Funktion die einen Datentyp(Datensatz) zurück gibt.
Wie soll der FehlerCode zurückgegeben werden? Den Ruckgabetyp auf object ändern
und entweder den Datentyp oder den Fehlercode zurückgeben?
Dann müsste zusätzlich vor dem zuweisen noch das object überprüft werden.

Leider ist mir die Abkürzung DAL nicht bekannt. Anderseits darfst Du Dir die prozedurale Welt nicht zu objektorientiert vorstellen. Natürlich ist mein 3. Beispiel etwas verkürzt dargestellt. Du hast wenn ich mich recht entsinne in einem Embeded-SQL gewisse Macros zur Verfügung gestellt bekommen die Neben dem SQL Fehler-code und einem weiteren redundanten aber DB-Systemunabhängigen (weil normierter) Return-Code no dies und das bekommen. Bei Erfolgsmeldung hat man dann einfach die Datensätze iteriert. Macht man heute eigetnlich genauso. Der generelle Unterschied zu früher ist halt nur, dass eine Exception die weiterverarbeitung bis zum ende des TRY-blocks fluchtartig verlässt (also eigentlich ein etwas der Strukturierten Programmierung widerstrebendes aber recht nützliches Verhalten, wenn man dieses Idiom kennt)

Zitat von cosmochaosmaker

Das würde doch den Code wieder unübersichtlich machen.
Sollte nicht die Klasse Flags bereitstellen um dies woanders genauer auszuwerten?

Wie gesagt Klassen kennt die Prozedurale Welt eigentlich nicht.

Zitat von cosmochaosmaker

Datenverwertung und Fehlerbehandlung währen doch so sauberer getrennt.
Was sagst Du?
lg, cosmo

Da hast du absolut recht. Jedoch sollte man eine gewisse Historie sehen bzw. verschiedene Programmierphilosophien/Praktiken sehen.

Nehmen wir doch mal das gute alte Pascal. Damit meine ich nicht die späteren Pascaldialekte wie z.B. Turbopascal, sondern die älteren Formen der Sprache.
Es gab dort Prozeduren (ohne Rückgabewerte aber Möglichkeit von ein und Ausgabeparmertern) und Funktionen, die normalerweise dafür verwendet wurden Berechnungsergebnisse zurückzugeben.
Im Vergleich dazu C dort gab es nur noch den Begiff der Funktionen, wobei das im wesentlichen sich nur um ein terminologischen Unterschied handelt. Aufjedenfall war es in C natürlich auch in den Standardbibliotheken üblich Returncodes als Erfolgs oder misserfolgsmeldungen zurück zugeben andererseits auch nicht selten als Wert. Also eine recht gemsichte angelegenheit ähnliches finden man auch noch in heutigen Standardbibliotheken, z.B. in Funtionen für die Stringanalyse.(RC= -1: zu suchendes Zeichen nicht gefunden und RC>=0 : Index wo zu suchendes Zeichen enthalten ist).
Also eine typsiche Vermischung von Erfolgsmeldung und Ergebniswert.
Es scheint halt praktikabler an der Stelle so zu verfahren, allerdings gilt es eigetnlich für sauberer Erfolgbewertung und weiterzuverarbeitender Wert zu trennen.

Also es werden nicht selten auch in hoch offiziellen Bibliotheken in manchen Fällen solches Vermischt ich vermute mal es ist ein Stückchen C-Pragmatismus.

Takidoso

Meine Güte,

dein Wissen macht mir Angst.
Du scheinst ein einer dieser "älteren" Cracks von damals zu sein.

Zitat von takidoso

Leider ist mir die Abkürzung DAL nicht bekannt. Anderseits darfst Du Dir die prozedurale Welt nicht zu objektorientiert vorstellen. Natürlich ist mein 3. Beispiel etwas verkürzt dargestellt. Du hast wenn ich mich recht entsinne in einem Embeded-SQL gewisse Macros zur Verfügung gestellt bekommen die Neben dem SQL Fehler-code und einem weiteren redundanten aber DB-Systemunabhängigen (weil normierter) Return-Code no dies und das bekommen. Bei Erfolgsmeldung hat man dann einfach die Datensätze iteriert. Macht man heute eigentlich genauso.

Was zu Thema DAL (Datenbank-Abstraktions-Layer)
Wie soll ich das verstehen? Vermeidest Du jetzt prinzipiell das Ergebnis zurückzugeben
und verwendest anstelle ReturnCodes und entscheidest dann den Wert auszulesen,
den Du derweil woanders hin gespeichert hast?
Ist das nicht ein bissel "pessimistisch programmiert"?.
Ich will Dich wirklich nicht kritisieren, nur verstehe ich den Sinn Vorgehensweise nicht ganz.
Vor allem wenn man von der Funktion einen Typ anstatt irgend einen Zahlenwert erwartet.

Nicht das Du mich falsch verstehst, ich meinte nicht generell.

Es gibt natürlich auch andere Scenarios wo vor dem Verwerten des Ergebisses,
der Erfolgsstatus gebraucht wird.
Quasi wenn Du Du dir sowas wie ein Objekt baust welches mit Read() usw arbeitet.
(wie beim IO.Stream) Dann ist es logischerweise praktikablerer mit einer Funktion,
die Daten zu lesen zu prüfen ob und wieviel gelesen werden konnte.
Oder wie Du schon sagtest best. StringFunktionen.

Andernfalls bin ich der Meinung das man es optimistischer lösen kann
und geilchzeitig einen klareren Ablauf sieht.
Ich finde es ist dann viel übersichtlicher was mit den Daten passiert,
weil sie gleich verwertet werden.
Ich prüfe zB auf != null und kann andernfalls einfach abbrechen (1 Zeile)
und werte dann den Fehler im "ErrorHandler" meiner Klasse mit hilfe der "Flags" aus.
Dann brauch ich den ReturnCode in der Funktion gar nicht zu überprüfen.
Ich mag das einfach nicht in den Methoden/Funtionen haben die mit den Ergebnissen arbeiten.
Das bläht sich dann alles so auf und wird für mich unübersichtlich.

Zitat von takidoso

Der generelle Unterschied zu früher ist halt nur, dass eine Exception die weiterverarbeitung bis zum ende des TRY-blocks fluchtartig verlässt (also eigentlich ein etwas der Strukturierten Programmierung widerstrebendes aber recht nützliches Verhalten, wenn man dieses Idiom kennt)

Sollte aber auch nur eine Notbremse sein find ich.
Exceptions als Programmflusssteuerung zu verwenden ist Schwachsinn.
Ausser man will von aussen einen Thread abbrechen
oder seine Propertys richtig wertzuweisungssicher machen usw. .

Zitat von takidoso

Also es werden nicht selten auch in hoch offiziellen Bibliotheken in manchen Fällen solches Vermischt ich vermute mal es ist ein Stückchen C-Pragmatismus.

Ich denke es ist nur ein Ding der Notwendigkeit.
Also Scenarios, bei denen der Erfolgsstatus bekannt sein muss,
bevor das Ergbnis verwertet wird.

lg, cosmo

Zitat von cosmochaosmaker

Meine Güte,

dein Wissen macht mir Angst.
Du scheinst ein einer dieser "älteren" Cracks von damals zu sein.

Keine Sorge, es gibt verschiedene Formen des Wissens. Ich habe als 15 Jähriger die ersten Programme geschrieben, wie vermutliche viele andere im ähnlichen Alter ebenso.
Es war halt in der frühen Mitte der 80'er, in der, so man interessiert war, mit Homecomputern nicht nur spielend sondern auch programmiertechnisch auseinandersetze. Damals hatte ich vor allem Neugier und teilweise Gelegenheit mich mit einigen verschiedenen Programmiersprachen zu beschäftigen, wobei es weniger in große Tiefen ging sondern mehr um die Philosophien der jeweiligen Sprachen. Insofern habe ich, selbst wenn ich mal so etwas wie Spezialwissen gehabt haben sollte, mich mehr für das prinzipielle interessiert.

Zitat von cosmochaosmaker

Vermeidest Du jetzt prinzipiell das Ergebnis zurückzugeben
und verwendest anstelle ReturnCodes und entscheidest dann den Wert auszulesen,
den Du derweil woanders hin gespeichert hast?

Ich bin mir nicht sicher, ob du da komplizierter denkst als es eigetnlich ist. Wenn Dir z.B. ein zugriff auf eine DB-Tabelle nicht geklappt hat, weil keine Connection, Statement falsch oder Constraint, der sich beschwert etc, ist es sinnlos irgendwelche Daten einlesen zu wollen. In heutigen Umgebungen bekommst du eine Exception und der fachliche code muss sich nicht damit rumschlagen und sieht halt auch fachlich aus. In einer Umgebung ohne Exception (so wie es halt früher war) hast Du mit einem if then else oder case-anweisung (in c ähnlichen Sprachen switch-anweisung) halt darauf reagiert, das ist eigentlich alles. Also so wie im 3. Beipiel.

Zitat von cosmochaosmaker

Ist das nicht ein bissel "pessimistisch programmiert"?.

...

Zitat von cosmochaosmaker

Vor allem wenn man von der Funktion einen Typ anstatt irgend einen Zahlenwert erwartet.

Ja es ist pessimistisch programmiert, man tut es ja nicht mit jeder beliebingen Funktion, sondern nur dann wenn etwas nicht klappen könnte, sei es aus Technischen oder aus Programmeirfehlergründen.
Normalerweise ist ja sowas nur dann der Fall wenn man mit anderen Systemen kommuniziert, typisches Beispiel DB oder Netzwerk.
Der prozedurale Ansatz wird in heutigen modernen Systemen natürlich nicht mehr gemacht, dafür gibt es halt mittlerweile Exception-Handling.

Zitat von cosmochaosmaker

Es gibt natürlich auch andere Scenarios wo vor dem Verwerten des Ergebisses,
der Erfolgsstatus gebraucht wird.
Quasi wenn Du Du dir sowas wie ein Objekt baust welches mit Read() usw arbeitet.
(wie beim IO.Stream) Dann ist es logischerweise praktikablerer mit einer Funktion,
die Daten zu lesen zu prüfen ob und wieviel gelesen werden konnte.
Oder wie Du schon sagtest best. StringFunktionen.

StringFunktionen sind ein typisches Beispiel wo das ganze ohne Exceptions gelöst wird, weil solche Fehler wirklich zu oft passieren können und vermutlich ja gar keine Exception-würdige Situation ist.

Zitat von cosmochaosmaker

Das bläht sich dann alles so auf und wird für mich unübersichtlich.

Genau das ist ja auch der Grund, warum man ungewöhnliche technische Probleme eben nicht mehr mit Fallunterscheidungen beglückt.

Zitat von cosmochaosmaker

Sollte aber auch nur eine Notbremse sein find ich.
Exceptions als Programmflusssteuerung zu verwenden ist Schwachsinn.

Wir beide sind da absolut konform, man sollte Exceptions nur als solche verwenden was sie nunmal auch sind, nähmlich Ausnahmen!

Zitat von cosmochaosmaker

Ich denke es ist nur ein Ding der Notwendigkeit.
Also Scenarios, bei denen der Erfolgsstatus bekannt sein muss,
bevor das Ergbnis verwertet wird.

Richtig, entweder man benötigt ein Ergebnis und es wäre falsch keines zu bekommen oder ein Ergebnis nicht zu bekommen hat innerhalb der Anwendung einen Semantischen Sinn.

Wo es allerdings Sinnvoll sein kann in seiner eigenen Anwedung Exceptions zu werfen ist z.B. wenn sichergestellt werden soll, dass die einer Mehtode dargebrachten Argumente koreckt sind oder nicht. Ein typisches Beispiel welches ich da rausgreifen mag wären z.B. sogenannte Funktionscodes.
Nehmen wir mal an eine routine erwartet als Argument unteranderem für die nähere Verarbeitungsspezifizierung einen sogenannten Funktionscode aus einer fest definierten Menge, dann kann es sinnvoll sein diesen code auf gültigkeit abzutesten einfachste Möglichkeit wäre das in einem switch/case - Konstrukt

Code :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// erlaubte funcCodes (TUH_DIES, TUH_DAS) func1 (int funcCode, Object arg1, Object arg2) {     switch (funcCode)     {         case TUH_DIES:               ....         break;         case TUH_DAS:               ....         break;         default: // in der Hoffnung, dass es nie zu dieser Exception kommt             throw new IllegalArgumentException("falscher Code"+funcCode);       } }

Mal abgesehen, dass IllegalArgumentException vermutlich in C# etwas anders heißen mag, ist der Sinn dieses Konstruktes der, dass man sicher ist, dass die Routine etwas tut oder aber sich beschwert. Damit wird sichergestellt, dass der Programmierer der die Routine aufruft dies auch zumindest in diesem Beispiel mit einem erlaubten Funktionscode tut. Trifft man also eine solche Exception in der Ausführung an, darf man sicher sein, das etwas zu korrigieren ist. Insofern ist aus meiner sicht es nicht notwendigerweise falsch in seinem Programm auch selbst Exceptions zu werfen, mit unter ersparrt das gerade in solchen Szenarios unnötige Analyse Zeit.
Aber wie Du schon bemerkt hast und auch ich immer wieder nur betonen kann, sind Exceptions als Ausnahmezustand anzusehen.

Takidoso

Vielen dank für deine Antwort.

Ich bin mir nicht sicher, ob du da komplizierter denkst als es eigetnlich ist. Wenn Dir z.B. ein zugriff auf eine DB-Tabelle nicht geklappt hat, weil keine Connection, Statement falsch oder Constraint, der sich beschwert etc, ist es sinnlos irgendwelche Daten einlesen zu wollen. In heutigen Umgebungen bekommst du eine Exception und der fachliche code muss sich nicht damit rumschlagen und sieht halt auch fachlich aus. In einer Umgebung ohne Exception (so wie es halt früher war) hast Du mit einem if then else oder case-anweisung (in c ähnlichen Sprachen switch-anweisung) halt darauf reagiert, das ist eigentlich alles. Also so wie im 3. Beipiel.

Ich verstehe was Du meinst.
Nur verwerte ich die Exception schon in der Klasse die die DB liest.
Sie hat ja nach meinem Gutdünken mit dem Rest nichts zu tun.
Wie gesagt, ich möcht das meine Objekte dies selber machen.
Der Rest wird via Flags geregelt.
Eine Flag kann ja auch einen ErrorString aus deinen Ressources repräsentieren.

Dein letztes Bspiel beschreibt auch genau die Situation, die ich mir auch unter einer Exception vorstelle.
Kommt dem nahe seine eine Propertys richtig wertzuweisungssicher machen.
Gutes Beispiel.
In disem Beispiel sieht man zB auch ganz gut, wie man Threads mit Exceptions einfach stoppen kann.
Danke für dein Statement. Das ist das bei weitem Beste, was ich bisher zu dem Thema gelesen hab.
Es bestätigt meine bisherigen Erfahrungen auf dem Gebiet, die ich mit selber angeeignet habe.
Und ich hab dadurch wieder eine bessere Sichtweise, für die Dinge ansich bekommen.

lg, cosmo

So, jetzt muss ich mich auch einmsichen

Deine Klassen können das nicht immer selber lösen. Entwickelst du zum Beispiel ein Framework inkl. der notwendigen Storage-Klassen etc. dann kann zb die Storage-Klasse Fehler bis zu einem bestimmten Punkt abfangen und selbst behandeln. Ausnahmen, sollten an dieser Stelle weitergereicht werden. Warum? Nun, es sollte der User auch wissen, dass eine Ausnahme aufgetreten ist.

Natürlich müssen hier auch unterschiedliche Dinge bedacht werden. Handelt es sich um eine 3-Tier, 2-Tier oder überhaupt nur um eine "Desktop-Anwendung". Bei einer 3-Tier-Anwendung macht es wenig Sinn Exceptions ganz zurück weiter zu reichen. Hier muss die Stelle definiert werden, an der es Sinn macht die Exception zu behandeln, um die Meldung dann entweder an den Logger zu übergeben, oder ein eventuellen Workflow auszulösen.

Und sicherlich machen eigene Exceptions Sinn. Genau an den Stellen, an denen Ausnahmen auftreten können. Logische Fehler zb. sollten auf keinen Fall durch Exceptions behandelt werden. Aber das sollte ansich auch klar sein.

Natürlich hat das Statement von unserem großen Brain Norbert gefehlt.
Nur leider Hatte ich bisher nicht die Gelgenheit in einem Team mit C# zu arbeiten.
Ich entwickle eher Desktop&DX-Anwendungen und Plattformübergreifende Lösungen.
Aber ich stimme mit Dir voll überein.

Auch bei Desktop-Anwendungen machen Exceptions Sinn. Diese können einfach an die Visualisierungs-Schicht weitergeleitet werden, um den User zu informieren was denn da nun eigentlich Sache ist. Aber wie schon oben erwähnt, es macht keinen Sinn, logische Fehler durch Exceptions abzudecken. Ebenso ist es sinnvoller Usereingaben ordentlich zu validieren um nicht in Exceptions zu laufen.

Und was genau meinst du in diesem Zusammenhang mit plattformübergreifende Lösungen? Anwendungungen, die sowohl unter zb. Windows als auch unter zb. Linus laufen? Ja? Hier hast du im Endeffekt die gleiche Problematik, nur unterschiedliche Systeme.

Weiters machen viele den Fehler, Exceptions unter C# gleich zu behandeln wie eben solche unter Java, vor allem wenn versucht wird, C# unter Linux zu programmieren. Das Problem hierbei ist, dass die Implementierung der Exceptions unter .NET nicht ident mit der Implementierung der Exceptions unter Java ist. Hier gibt es einige signifikante Unterschiede, was bei Nichtbeachtung natürlich gleich mal ausartet bzw. ohnehin vom Compiler nicht akzeptiert wird.

Zitat von Norbert Eder

Und was genau meinst du in diesem Zusammenhang mit plattformübergreifende Lösungen? Anwendungungen, die sowohl unter zb. Windows als auch unter zb. Linux laufen? Ja? Hier hast du im Endeffekt die gleiche Problematik, nur unterschiedliche Systeme.

Das ist mir vollkommen klar.
Ich hab das schlecht ausgedrückt.
Ich meinte plattformübergreifende Internetschnittstellen (hauptsächlich zwischen C# & PHP (SOAP), Sockets)
Liebend gerne würd ich mal mit jemand was in C# programmieren damit ich mal kennen lerne,
inwiefern man mit Exceptions ferfährt, wenn man sich im Team die Module der Anwendung zureicht.

Ich hab aber bisher immer darauf geachtet, und um mir selber "auf die Finger zu klopfen",
kleinerere Teilprojekte mit Exceptions an Stellen auszustatten,
bei denen der Rest des Vorgangs nach der Aushahme keine weitere Bedeutung mehr hat.
Oder die Parameter, die für die Aufgabe des Teilprojektes notwendig sind,
nicht mit den Vorgaben übereinstimmen.

Weiters machen viele den Fehler, Exceptions unter C# gleich zu behandeln wie eben solche unter Java, vor allem wenn versucht wird, C# unter Linux zu programmieren. Das Problem hierbei ist, dass die Implementierung der Exceptions unter .NET nicht ident mit der Implementierung der Exceptions unter Java ist. Hier gibt es einige signifikante Unterschiede, was bei Nichtbeachtung natürlich gleich mal ausartet bzw. ohnehin vom Compiler nicht akzeptiert wird.

Interessant, könntest die Unterschiede der Exceptionimplementierungen beider Sprachen
bitte näher ausführen oder eine Lektüre dazu empfehlen.

Naja, aufpassen. Das hat mit der Entwicklung im Team nichts zu tun. Nur weil zb eine 3-Tier-Anwendung entwickelt wird, bedeutet dies nicht zwangsweise, dass daran mehr als eine Person arbeitet. Die Exceptions laufen ohnehin unabhängig davon.

Exceptions unter Java und C#
Prinzipiell ist hier vieles gleich implementiert. In beiden Sprachen werden die try-catch-finally-Blöcke unterstützt und natürlich haben beide auch eine komplette Hierarchie der Exceptions, sowie das Mapping einer Exception in eine andere Exception (unter C# -> InnerException).

Beide Sprachen erlauben das Auslesen des Stack-Traces. Aber nur unter Java kann er auch geändert werden.

Weiters deklarierst du in Java in der Signatur der Klasse oder der Methode welche Exceptions von der Klasse/Methode geworfen werden. In C# ist das nicht so. Die Gründe hierfür aus Sicht von Microsoft hab ich mal für euch rauskopiert, weils mir einfach zu blöd ist, das jetzt aus dem Kopf zu schreiben:

1. Versioning
2. Productivity and code quality
3. Impracticality of having class author differentiate between "checked" and "unchecked" exceptions
4. Difficulty of determining the correct exceptions for interfaces.

Versioning

If C# required exception specifications then versioning would be more difficult. Once a class is published with a given set of "throws" exceptions, nothing could ever be added to that set since it would invariably break every client. The clients would be missing either a catch clause for the new exception or a matching "throws" declaration.

Not being able to change implementations to deal with new exceptional conditions drastically limits how class libraries can evolve, and thereby unnecessarily constrains real-world projects with long time spans. As an example, consider a class that exposes a function which doesn't throw any exceptions in its first version. Later, a new exceptional condition is found. The class author must choose between two unattractive options: catch and ignore the exception, or break compatibility.

Productivity and code quality

Examination of small programs leads to the conclusion that requiring exception specifications could both enhance developer productivity and enhance code quality, but experience with large software projects suggests a different result; decreased productivity and little or no increase in code quality.

Requiring exception specifications decreases developer productivity because of the sheer proliferation of exception specifications. This proliferation proceeds in two dimensions:

1. First, the number of members is generally monotonically increasing over time. That is, modern exception handling allows a division of work between the code that raises the exception and the code that handles it. These pieces of code may be separated by intervening code. For example, A calls B, B calls C, C calls D, and D raises an exception that is eventually handled by A. If C# required exception specifications, then each of A, B, C, and D would have to contain exception-handling related code even though only A and D do any actual work related to the exception.
2. The number of possible exceptions. The number of exceptions is unquestionably large. Any code that adds two numbers could result in an overflow exception, any code that divides two numbers could result in a divide by zero exception, and any code that instantiates an object could result in an out of memory exception.

The lack of an increase in code quality is related to the response of developers to the proliferation of exception specifications. Developers who carefully examine all of the exception specification errors reported by the compiler might see an increase in code quality, but this would come at the expense of productivity. A single new exceptional condition could result in the need to update hundreds of exception specifiers throughout the program. On the other hand, a less thorough developer has several available options that are far cheaper but also far less likely to increase code quality:

1. Reuse an existing exception for a purpose that doesn't quite fit.
2. Catch the exception and ignore it. This is obviously dangerous.
3. As a matter of practice, add a generic exception specification to each and every member, thus subverting the feature completely.
4. Mindlessly add whatever exception specifications the compiler requires. (For better or worse, automation of this process is inevitable.)

Each of these options has a low but non-zero implementation cost, and none are likely to increase code quality. This is not a pretty cost-benefit picture.

A better strategy is for client code, that is, code that is using a class library, to include both generic exception handling and specific exception handling. Generic exception handling is performed centrally, and generically deals with all exceptions. Specific exception handling checks for a smaller number of exceptions; the ones that the client code is specifically prepared to respond to or recover from. This split between generic and specific exception handlers is practically required since some exceptions (e.g., out of memory exceptions) can occur in many program locations but are rare in frequency. All client code needs to have some generic exception handling.

For another discussion of this point, take a look at: http://www.mindview.net/Etc/Discussi...ckedExceptions

Impracticality of having class author differentiate between "checked" and "unchecked" exceptions

Some systems allow a developer of a class to differentiate between "checked" exceptions (those that are enforced by the compiler) and "unchecked" exceptions (those that are not). In such systems, to make a decision about whether to employ a checked or unchecked exception, a class author would have to judge whether a given exception can occur throughout a given program and whether recovery from the exception is possible. We think that this is an impossible decision to make since these factors are primarily dependent on the code that is using the class rather than the class itself.

Difficulty of determining the correct exceptions for interfaces

Checked exceptions require that interface methods define which exceptions that may throw. If an interface method throws a limited set of exceptions, that places a constraint on interface implementers to use that same set.

This can present a problem if a specific implementation calls methods that throw exceptions that are not in the interface definition. The implementation must do something to get his code to compile, and there are several options:

1. Throw an unchecked exception from the implementation
2. Catch the exception, and throw one that the interface defines
3. Wrap the exception in one that the interface defines
4. Create an exception that derives from an exception the interface defines.
5. Swallow the exception

None of these workarounds are without problems. Using an unchecked exception or one that the interface does throw may not be appropriate. Wrapping the exception or creating a derived exception may work, but both hide information about what really happened from the user. Swallowing the exception is also a bad idea.

Ach darum ging es Dir. Ich dachte Du meintest jetzt was anderes als das.
Ich hab ich doch den Link dazu gepostet.
Den Unterschied kenn ich und bin ehrlich gesagt für das ExceptionHandling von C#.
Glaub, wir hab uns grad falsch verstanden, sorry.