[C#] Try/Catch forceren.

[Spiral]

Is het mogelijk om bij een stuk code een try/catch te forceren, zodat de code alleen compileert als je een try catch om je betreffende stuk code heen hebt. Ik heb het welleens gezien dacht ik met database connectie ergens naar toe, maar kan het niet meer voor de geest halen om een voorbeeld te tonen.

voorbeelde

C#:

private void DoeJeDing()
{
if(this.getType() == typeof(mijnobject))
      DoeDitEnDat();
else
      throw new Exception("Kan mijn ding niet doen");
}

C#:

private void JaDoeJeDing()
{
       DoeJeDing();
}

Nu wil ik eigenlijk dat hij begint te zeuren bij JaDoeJeDing als ik 'm ga compileren.

[robbert]

Java:

private void DoeJeDing() throws Exception
{
if(this.getType() == typeof(mijnobject))
      DoeDitEnDat();
else
      throw new Exception("Kan mijn ding niet doen");
}

Zoiets zou het in java zijn, kan C# niet ook zoiets?

[Spiral]

Nee, helaas ondersteund .NET dit niet ... ik ben wel verder gekomen met m'n zoektocht:

http://www.thescripts.com/forum/thread262938.html

Kan iemand dit verifiëren dat het inderdaad niet kan?

[whoami]

Java heeft checked exceptions, .NET niet.

[roy-t]

ik snap eigenlijk niet waarom je zou willen dat er altijd een try catch omheen staat.

maakt het onnodig langzamer, en is maar al te vaak niet nodig, ook zou je het voor stukken waar je het 'eventjes niet op zet' gewoon bookmarkjes kunnen maken en die even doorbladeren op het moment dat je gaat compileren. Elke goede IDE support dat wel

[whoami]

Een try / catch maakt je code niet langzamer.
Het throwen van een exceptie is duur, maar of er nu een try / catch staat of niet, maakt niet echt iets uit qua performance.

[Verwijderd]

Waarom een try/catch forceren? Wat als een ontwikkelaar die tegen jouw routine aan programmeert een generieke exception handler gebruikt die die catch overbodig maakt?

[DrDelete]

Kun je aangeven wat je wilt bereiken met jouw code. Zoals al eerder aangegeven is, is het onzinnig om overal try-catch blokken te plaatsen zonder dat je een specifieke richting op wil met de catch...

[JKVA]

Verwijderd schreef op maandag 13 augustus 2007 @ 00:08:
Waarom een try/catch forceren? Wat als een ontwikkelaar die tegen jouw routine aan programmeert een generieke exception handler gebruikt die die catch overbodig maakt?

Misschien een stukje bewustwording forceren? Verder zie ik er ook weinig nut in.

Checked exceptions uit Java zijn wel praktisch zodat je duidelijk in je method signature kunt aangeven wat de exceptionele gevallen zijn, maar waarom je dat per sé met een catch moet afvangen is mij onduidelijk. Gewoon doorgooien is regelmatig beter (generieke foutafhandeling ofzo).

[Jaspertje]

Het is volgens mij voor een IDE erg lastig om dat te bepalen, want waar moet dan precies een try/catch omheen? Ik heb (heel lang geleden) wel iets met rules gezien in Team studio, maar dat ging volgens mij meer om het inchecken in Sourcesafe en 100% zeker daarvan ben ik ook niet meer

[mOrPhie]

Jaspertje schreef op maandag 13 augustus 2007 @ 09:02:
Het is volgens mij voor een IDE erg lastig om dat te bepalen

Het gaat hier volgens mij niet om de IDE, maar om het in de assembly te forceren. Als de CLI het zou ondersteunen, dan zou de compiler het kunnen detecteren wanneer je tegen een dergelijke assembly aan praat.

[EfBe]

Dit heeft totaal geen zin. Een catch is alleen nuttig als je daar ook de afhandeling van je exceptions gaat doen. Anders kun je hem net zo goed weglaten en dan bubblet die exception gewoon naar boven.

[Spiral]

Ik maak een dll waarin o.a. dit verwerkt zit, en als de dll gebruiken wil ik graag dat ze deze netjes afvangen.

C#:

public new void Add(cB b)
{
if(t == typeof(cV))
       base.Add(b);
else if (t == typeof(cE) && b.GetType() == typeof(cE))
       throw new Exception("De e is de laatste k, \nhierachter kan geen k geplaatst worden.");
else if (t == typeof(cE) && b.GetType() == typeof(cV))
       throw new Exception("Achter een e mag geen v geplaatst worden.");
else
       throw new Exception("Object " + b.GetType().ToString() + " kan niet worden herkend in de klasse cList");
}

[DrDelete]

Spiral schreef op maandag 13 augustus 2007 @ 09:39:
Ik maak een dll waarin o.a. dit verwerkt zit, en als de dll gebruiken wil ik graag dat ze deze netjes afvangen.

C#:

public new void Add(cB b)
{
if(t == typeof(cV))
       base.Add(b);
else if (t == typeof(cE) && b.GetType() == typeof(cE))
       throw new Exception("De e is de laatste k, \nhierachter kan geen k geplaatst worden.");
else if (t == typeof(cE) && b.GetType() == typeof(cV))
       throw new Exception("Achter een e mag geen v geplaatst worden.");
else
       throw new Exception("Object " + b.GetType().ToString() + " kan niet worden herkend in de klasse cList");
}

Kun je de types verklaren die buiten de scope van de method gebruikt worden ? Ze zijn voor mij onduidelijk.

Tip: als je het binnenkomende parameter gaat checken om uiteindelijk een exception te throw'en raad ik aan om een ArgumentException of een afgeleide daarvan (ArgumentOutOfRange of ArgumentNull) te gebruiken. Dit is in lijn met de design guidelines van MS.

Mocht de overall state van het object nadat je een argument check heb gedaan niet goed zijn, dan moet je InvalidOperationException throw'en. Het throw'en van de generieke System.Exception wordt afgeraden. Je hebt als ontwikkelaar helemaal niks aan, het enige wat gebeurt is, als het niet wordt afgevangen, dat het omhoog borrelt naar de final exception handler van .NET waardoor je de bekende popup in beeld krijgt, je kunt dan beter de InvalidOperationException gebruiken, die is daar voor bedoeld.

Lees aandachtig de Design Guidelines For developing class libraries door, vooral de sectie "Design Guidelines for Exceptions". Check http://msdn2.microsoft.com/en-us/library/ms229042.aspx

[Woy]

Spiral schreef op maandag 13 augustus 2007 @ 09:39:
Ik maak een dll waarin o.a. dit verwerkt zit, en als de dll gebruiken wil ik graag dat ze deze netjes afvangen.

C#:

public new void Add(cB b)
{
if(t == typeof(cV))
       base.Add(b);
else if (t == typeof(cE) && b.GetType() == typeof(cE))
       throw new Exception("De e is de laatste k, \nhierachter kan geen k geplaatst worden.");
else if (t == typeof(cE) && b.GetType() == typeof(cV))
       throw new Exception("Achter een e mag geen v geplaatst worden.");
else
       throw new Exception("Object " + b.GetType().ToString() + " kan niet worden herkend in de klasse cList");
}

Ik zou gewoon duidelijk in de documentatie zetten welke exceptions er gegooid kunnen worden. Het is daarna toch aan de gebruiker van de dll om te bepalen wat hij met een foutsituatie wil doen.

[DrDelete]

rwb schreef op maandag 13 augustus 2007 @ 10:56:
[...]

Ik zou gewoon duidelijk in de documentatie zetten welke exceptions er gegooid kunnen worden. Het is daarna toch aan de gebruiker van de dll om te bepalen wat hij met een foutsituatie wil doen.

Dat gaat met de codevoorbeeld van de poster niet lukken, een catch leggen op een generieke System.Exception heeft absoluut geen zin, wel op heel specifieke.

[Spiral]

DrDelete schreef op maandag 13 augustus 2007 @ 10:53:
[...]
Kun je de types verklaren die buiten de scope van de method gebruikt worden ? Ze zijn voor mij onduidelijk.

Lees aandachtig de Design Guidelines For developing class libraries door, vooral de sectie "Design Guidelines for Exceptions". Check http://msdn2.microsoft.com/en-us/library/ms229042.aspx

Ik ben de Add van List<T> aan het overschrijven en deze kan meerdere types bevatten. variabele t is het type dat de Add van de lijst aanroept. cV en cE erven over van cB. Ik zal die guideline doornemen. Ik werk altijd met Exception, nooit gedacht aan ArgumentException, wat natuurlijk wel heel logisch is om te gebruiken hiervoor !

[Woy]

DrDelete schreef op maandag 13 augustus 2007 @ 11:00:
[...]


Dat gaat met de codevoorbeeld van de poster niet lukken, een catch leggen op een generieke System.Exception heeft absoluut geen zin, wel op heel specifieke.

Nee handig is het zeker niet, Je wilt tenslotte niet in je catch op de message gaan filteren. Maar ik had het meer over de vraag van de ts.
Gewoon netjes documenteren wat er kan gebeuren. Het aanroepende programma is er daarna verantwoordelijk voor