Waarschuwen als uitzondering niet wordt afgehandeld

Zijn er technieken of hulpprogramma's van derde partijen die waarschuwingen genereren als code de mogelijkheid heeft om een ​​uitzondering te genereren die niet is ingepakt in een blok try/catch ?

2
Waarom zou daar? Meestal is het erg goed om geen uitzondering te vangen.
toegevoegd de auteur Uwe Keim, de bron
Ik heb een uitzonderingsklasse op maat die ik in sommige gevallen gebruik. Deze uitzonderingen moeten worden opgevangen omdat ik niet wil dat de toepassing tot stilstand komt. Ze zijn niet zo kritisch als uit geheugen uitzonderingen of iets dergelijks.
toegevoegd de auteur MarkP, de bron
Maar kunnen ze daadwerkelijk worden behandeld? Ik denk dat je het punt mist; uitzonderingen mogen alleen worden gevangen wanneer er een redelijke handelwijze is om daarop te reageren. Anders moet uw app tot een "stopmoment" komen (d.w.z. snel falen). Als u uw collega's niet kunt vertrouwen om de juiste code te schrijven, dan heb ik grotere problemen die ik vrees.
toegevoegd de auteur Ed S., de bron
Heeft u de gewoonte om alle code in try {} catch {} blokken in te pakken? Uit uw vraag blijkt dat u de uitzonderingen niet correct gebruikt.
toegevoegd de auteur Oded, de bron

3 antwoord

Ik zou willen voorstellen dat je misschien beter kunt denken aan waarom code uitzonderingen genereert, in tegenstelling tot eenvoudig en zonder verdere overweging, moet je eisen dat alle code wordt ingepakt in een of andere try/catch/finally. (Overigens, als dit mogelijk zou zijn, zou het triviaal zijn om het weg te laten gaan - ontwikkelaars zouden het hoofdpunt van een try/catch en geen waarschuwingen meer kunnen inpakken).

Code Contracts is a tool that won't do what you're asking for here, exactly, but it will help you reason about your code's run time behavior at compile time via compiler warnings. This will tell you things like when a client call deferences a return value and the service method might return null. This is getting to the root of exception-causing behaviors rather than just demanding that you handle them. In this case, you have a bad programming assumption -- you don't want to catch this exception, you want to eliminate it by preventing it from happening in the first place.

Ik zou uitzonderingsafhandeling kunnen besparen voor plaatsen waar u te maken hebt met externe factoren waarover u geen controle hebt (de gebruiker ontkoppelt bijvoorbeeld de netwerkkabel terwijl uw app een bestand downloadt). Het klinkt voor mij alsof je op zoek bent naar gecontroleerde uitzonderingen in Java-stijl, die C# niet heeft. Maar als u kijkt naar de XML-opmerkingen van de methode voor externe bibliotheken, kunt u zien welke uitzonderingen ze kunnen genereren en deze specifieke gevallen afhandelen. Als je dit alleen echt doet voor externaliteiten (en Code Contracten gebruikt om interne aannames te beheren), zal de hoeveelheid extra tijd die je besteedt niet veel zijn.

3
toegevoegd

Samen met het antwoord van Erik (upwards van hem):

Uitzonderingen zijn er om een ​​manier te bieden om het systeem te informeren dat er iets abnormaals is gebeurd. Ze zijn er niet om een ​​handige manier te bieden om een ​​methode te laten communiceren met de aanroepcode.

Als uw methoden pass/fail-situaties hebben, moeten ze een Boolean-vlag retourneren. Als ze een beetje ingewikkelder zijn, zoals het moeten terugkeren van statuscodes, dan zou je een struct of class als resultaat moeten gebruiken.

Kort samengevat: als u merkt dat u veel aangepaste uitzonderingen gebruikt, doet u het verkeerd.

0
toegevoegd

Er is een vraag met ongeveer hetzelfde probleem . Dat is hoe te detecteren of een code een fout zou kunnen veroorzaken. Ik weet niet zeker of deze vraag als een dupe zou tellen, want het lijkt erop dat je het vooraf gecompileerd wilt doen, waarschuwingen krijgt

Echter, het antwoord op de geaccepteerde vraag daar:

In navolging op mijn vorige antwoord heb ik een basis gemaakt   uitzonderingzoeker. Het maakt gebruik van een op reflectie gebaseerde ILReader-klasse,   hier beschikbaar op het MSDN-blog van Haibo Luo. (Voeg gewoon een verwijzing toe naar de   project.)

     

[...]

     

Om samen te vatten: dit algoritme somt recursief (depth-first) any op   binnen de opgegeven methode, door het lezen van de CIL   instructies (evenals het bijhouden van reeds bezochte methoden). Het   onderhoudt een enkele lijst met verzamelingen die kunnen worden gegooid met behulp van een   HashSet-object, dat aan het einde wordt geretourneerd. Het bovendien   onderhoudt een reeks lokale variabelen en een stapel om te behouden   volgen van uitzonderingen die niet meteen worden gegooid nadat ze zijn   aangemaakt.

Als u het niet erg vindt om een ​​post-compilatiecode-analyse uit te voeren en op basis van IL-code, kunt u proberen het fragment Noldorin te gebruiken dat in die vraag is gepost.

0
toegevoegd