31. marts 2008 - 15:21Der er
7 kommentarer og 1 løsning
Exception i C#
Jeg ved at man i java, hvis man havde en metode og den kastede en exception.
public void bla() throws Exception;
Så skulle man lave en try/catch, ellers kunne man ikke kompilere. dette er/var en god sikkerhed for, at der ikke blev overset noget. Nu er jeg så gået på c#, men :
Hvis en metode caster en exception, som man nu engang har fortalt, så behøber man ikke lave en try/catch, hvis fejlen sker, så er det først når man løber ind i den, at man får det afvide.
Og det er ikke godt, hvis det er en kunde der ser det.
Er der ikke en måde, at få C# til at påkræve at man tager hånd om Exception, eller som minimun, selv skrivende exception.
bitmatic kom med et svar, du har jo svaret på det.
Når jeg tænker over det, så har han jo ret på mange ting. Jeg kan godt se det for mig, hvis man har så mange exception.
Men hvad så hvis du skal lave noget backend, som skal være så stabilt som det kan. Det ville da være rart, at kræve at der bliver taget hånd om dem, eller at den siger, at der kan kastes en exception. Istedet for at kunden skal se det.
Det kunne fx. Være at vi skulle overføre 100 kr. fra en konti til en anden. Så skal vi jo bruge disse exception til at finde ud af, om noget gik galt.
Eller anden form for data, som skulle være 100% iorden.
Personligt mener jeg at checked exceptions har en stor positiv effekt på mindre erfarne - de får vredet armen rundt og bliver gjort opmærksom på at der kan ske fejl og en mindre positiv effekt for mere erfarne derved at dokumentation af mulige exceptions er bedre.
----
Min skepsis overfor artiklen går på:
1) Det fremgår ikke specielt tydeligt at Java understøtter både checked og unchecked exceptions. Som udvikler kan man selv vælge hvda ens kode skal bruge. Man hænger naturligvis på andres valg for det kode man bruger af andres.
2) Hans syn på exception håndtering:
No, because in a lot of cases, people don't care. They're not going to handle any of these exceptions. There's a bottom level exception handler around their message loop. That handler is just going to bring up a dialog that says what went wrong and continue.
In the finally, you protect yourself against the exceptions, but you don't actually handle them. Error handling you put somewhere else. Surely in any kind of event-driven application like any kind of modern UI, you typically put an exception handler around your main message pump, and you just handle exceptions as they fall out that way. But you make sure you protect yourself all the way out by deallocating any resources you've grabbed, and so forth.
som efter min mening er et alt for forsimplet billede af behovet for exception handling. Der er masser af tilfælde hvor det er modellen. Men der er altså også tilfælde hvor det ikke er modellen - specielt ved større server applikationer.
3) Hans syn på exceptions i interfaces:
Adding a new exception to a throws clause in a new version breaks client code. It's like adding a method to an interface. After you publish an interface, it is for all practical purposes immutable, because any implementation of it might have the methods that you want to add in the next version. So you've got to create a new interface instead. Similarly with exceptions, you would either have to create a whole new method called foo2 that throws more exceptions, or you would have to catch exception D in the new foo, and transform the D into an A, B, or C.
The trouble begins when you start building big systems where you're talking to four or five different subsystems. Each subsystem throws four to ten exceptions. Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of exceptions you have to deal with. You end up having to declare 40 exceptions that you might throw. And once you aggregate that with another subsystem you've got 80 exceptions in your throws clause. It just balloons out of control.
som ikke korrekt beskriver hvordan checked exceptions bruges. Et givet lag eller en given komponent har et interface - det interface inkluderer exceptions - en eller flere egen definerede exceptions - implementations specifikke exceptions håndteres enten fuldtud elle rdelvis og i sidste tilfælde smides der en egen defineret exception videre til laget ovenpå. Det er ganske almindelig encapsulation praksis.
4) Hans konklusion:
In the large, checked exceptions become such an irritation that people completely circumvent the feature. They either say, "throws Exception," everywhere; or—and I can't tell you how many times I've seen this—they say, "try, da da da da da, catch curly curly." They think, "Oh I'll come back and deal with these empty catch clauses later," and then of course they never do.
som ganske vist er delvist rigtig - det sker, men hvis man skal fjerne features fra et sprog fordi det kan bruges forkert, så kan man fjerne mange features !
----
Exceptions er som oftest et mareridt at få til at virke fornuftigt. Men det er ikke en god løsning i alle tilfælde bare at ignorere problemet.
Og jeg tror faktisk godt at Anders Hejlsberg ved dette.
Hans hoved pointe er god nok. Hvis han føler at checked exceptions the Java way ikke er den optimale løsning, så er det meget bedre ikke at indføre checked exceptions og vente indtil man har en bedre model - eller finder ud af at the Java way er det mindste onde.
Som det nok allerede er gået op for dig, så er dette ikke muligt i C#, jeg må så indrømme at dele hen af vejen er jeg enig med Anders. Men det er både godt og ondt.
Jeg er dog uenig i at det har en god effekt på mindre erfarne, her mener jeg faktisk lige det modsatte.
Det er fair nok at vi får sikret at vores program ikke går ned fordi udviker X blev tvunget til at behandly FooException, men hvis man har nogle ordenlige arbejds processer med tests osv så skal vi nok fange det problem, og med en ordenlig udviklings metode også tidligt nok til det ikke bliver dyrt.
Men tvinges de til det, ender det som oftes med tomme handlers, dermed begraver man problemet og ens applikation ser på overfladen ud til at virke, indtil man så opdager en underlig adfærd.
Og det jeg oplever til daglig er at hvis applikationen går ned fordi man har glemt at håndtere en exception, jamen så er fejlen typisk nem at spore og dermed rette, men har man pluselig en exception der er fanget et sted og skulle der måske være gjort noget ved den, kan det være et rent helvede at finde ud af hvor og hvorfor.
Så derfor er jeg af den modsatte holdning, jo mere erfaring man har med exceptions og ved hvad man skal gøre med dem, både i det lokale tilfælde og inden for den applikation man er i gang med at udvikle, så giver checked exceptions mere og mere værdi, fordi de fungere som en reminder til at man lige skal huske at håndtere denne exception. Hvor i C# skal man læse sig til hvilke det er man skal håndtere, som afhængigt af hvilke API'er man arbejder med, kræver at man læser dokummentation.
Men nok om det.
Det du istedet kan gøre er jo på en pen måde at fortælle om dine exceptions i kommentarerne.
/// <exception cref="System.SomeException">Some explanation</exception> /// <exception cref="System.SomeOtherException">Some Other explanation</exception>
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
