Codenavigation durch Exceptions?

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.
 
Norbert Eder hat gesagt.:
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/Discussions/CheckedExceptions

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#. :D
Glaub, wir hab uns grad falsch verstanden, sorry. :-(
 
Zurück