[C#] catch-blok wordt niet uitgevoerd

[_Thanatos_]

Ik probeer uit een stuk opgevraagde HTML van een webpagina een Encoding te ontfutselen met Encoding.GetEncoding(charset). Geen probleem. Werkt.

Maar wat nou als de gegeven charset niet bestaat of niet ondersteund wordt door het OS? Ik simuleer die situatie door moedwilling een foute charset op te geven:

C#:

try {
   Encoding Result = Encoding.GetEncoding("blaat");
   return Result;
}
catch (NotSupportedException) {
   return Encoding.ASCII;
}

Volgens de help gooit GetEncoding een NotSuppertedException op, als de gegeven charset niet bestaat, en volgens mij gebeurt dat ook. Het is een webservice, dus ik zie geen mooi dialoogje naar voren ploppen; ik zie alleen in de browser de melding van de exception, en die komt (volgens de help) overeen met het type exception dat ik catch:

code:

blaat is not a supported encoding name.
Parameter name: name

Maar, waarom komt ie dan niet in het catch-block terecht, om netjes een algemene ASCII-encoding terug te geven?

[OZ-Gump]

Misschien moet je toch iets verder gaan met debuggen:
- voeg nog een catch toe voor een algemene exception en toon deze
- schrijf zaken weg naar Debug, dan zie je wat er gebeurt
- attach aan aspnet_wp.exe en zet een breakpoint
- vertel ons wat er gebeurd is

[_Thanatos_]

Ik doe het met VS.NET, dus debuggen gaat sowieso al vrij makkelijk. Hij komt dus *echt* niet in dat catch-blok.

Maar, heb ik net stiekem geprobeerd, als ik een catch doe op een algemene exception, dan doet ie het wel, en dan blijkt er een ArgumentException opgegooit te worden.

Maw, de help (MSDN installatie) is gewoon niet correct (is dat ergens te melden trouwens?)

[OZ-Gump]

Is toevallig de inner exception niet een 'NotSupportedException'?

Overigens kun je hier feedback geven en een bugreport sturen, maar voor dat laatste heb je wel een PassPort nodig...

[ Voor 4% gewijzigd door OZ-Gump op 21-07-2005 10:15 ]

[Zoijar]

Je kan sowieso beter een algemene exception afvangen, toch? Wat als er iets anders verkeerd gaat? Dan wil je dat je programma exit? Of wil je dan ook gewoon ASCII encoding gebruiken?

[Korben]

Mocht je Visual Studio 2005 Beta 2 gebruiken, dan is die ArgumentException wél correct:

quote: msdn

Exception	Condition
ArgumentException	name is not a valid code page name. -or- The code page indicated by name is not supported by the underlying platform.

[Korben]

Zoijar schreef op donderdag 21 juli 2005 @ 10:22:
Je kan sowieso beter een algemene exception afvangen, toch? Wat als er iets anders verkeerd gaat? Dan wil je dat je programma exit? Of wil je dan ook gewoon ASCII encoding gebruiken?

Algemene exceptions afvangen is not done, dat doe je alleen in debug builds. Je moet er namelijk vanuit kunnen gaan dat je code doet wat het moet doen en dat er geen andere dingen verkeerd gaan.

[OZ-Gump]

Algemene exceptions afvangen is not done

Dat is nog een stellige uitspraak die je daar doet. Ik neem namelijk aan dat wanneer jij een bestand wil openen, dat je dan niet catch blokken schrijft voor
- bestand niet gevonden
- bestand in gebruik
- bestand kon niet geopen worden
- geen vrije filenumbers beschikbaar
- whatever...

Dat je specifieke fouten wil afvangen en daarop wil reageren dan snap ik dat natuurlijk. Je moet echter in sommige gevallen ook de mogelijkheid hebben om 'Overige fouten' af te vangen.

[_Thanatos_]

Helaas, de InnerException is null, dus dat is em ook niet. Maargoed, ik vang nu ArgumentException af, en in het try-block staat *alleen* dat ene GetEncoding statement. Een vrij kleine kans dus dat er nog andere exceptions opgegooit kunnen worden.

[lier]

Korben schreef op donderdag 21 juli 2005 @ 10:26:
[...]

Algemene exceptions afvangen is not done, dat doe je alleen in debug builds. Je moet er namelijk vanuit kunnen gaan dat je code doet wat het moet doen en dat er geen andere dingen verkeerd gaan.

Heb jij enig idee hoeveel (onverwachte) fouten zich kunnen voordoen ?
Inderdaad zoals hierboven aangegeven werk je een aantal "verwachte" exceptions uit, maar je laat nooit aan het toeval over dat een niet gespecificeerde exception optreedt die niet afgevangen wordt.

Conclusie, altijd een catch(Exception ex) aan het eind

[_Thanatos_]

Maar gezien het een webservice is, wordt een eventuele andere exception altijd "netjes" opgevangen en wordt er een SoapException omheen gevouwen (mits je de webservice via SOAP aanroept...) Het is niet zo dat het hele ding instort. Het is gewoon 1 request dat dan mislukt.

[ Voor 4% gewijzigd door _Thanatos_ op 21-07-2005 10:47 ]

[Zoijar]

Korben schreef op donderdag 21 juli 2005 @ 10:26:
Algemene exceptions afvangen is not done, dat doe je alleen in debug builds. Je moet er namelijk vanuit kunnen gaan dat je code doet wat het moet doen en dat er geen andere dingen verkeerd gaan.

Dat zou moeten, maar wat als het niet het geval is? Exceptions zijn lastig te testen, tenzij je een formeel correctheids bewijs van je code geeft. Als je een exception niet vangt, dan abort je programma. Dat lijkt me niet echt wenselijk. Meestal maakt het niet uit wat er fout gaat, maar wil je de operatie gewoon opnieuw proberen of cancellen als er iets fout gaat. Ga jij al je library code doorspitten om te kijken of er niet per ongeluk toch een andere exception gegooid wordt? En zeg niet dat dat niet gebeuren kan, want kijk maar naar de TS zijn probleem. En in de toekomst? Blijkbaar heeft de nieuwe C# lib iets veranderd en wordt er een andere exception gegooid. Ga je dan al je code aanpassen? Nouja, aanpassen, als dat kan. Want je weet niet van de fout totdat het in een exceptioneel geval zich voordoet. Daarom ben ik het niet eens met je uitspraak.

[riezebosch]

Zoijar schreef op donderdag 21 juli 2005 @ 10:48:
[...]

Dat zou moeten, maar wat als het niet het geval is? Exceptions zijn lastig te testen, tenzij je een formeel correctheids bewijs van je code geeft. Als je een exception niet vangt, dan abort je programma. Dat lijkt me niet echt wenselijk. Meestal maakt het niet uit wat er fout gaat, maar wil je de operatie gewoon opnieuw proberen of cancellen als er iets fout gaat. Ga jij al je library code doorspitten om te kijken of er niet per ongeluk toch een andere exception gegooid wordt? En zeg niet dat dat niet gebeuren kan, want kijk maar naar de TS zijn probleem. En in de toekomst? Blijkbaar heeft de nieuwe C# lib iets veranderd en wordt er een andere exception gegooid. Ga je dan al je code aanpassen? Nouja, aanpassen, als dat kan. Want je weet niet van de fout totdat het in een exceptioneel geval zich voordoet. Daarom ben ik het niet eens met je uitspraak.

De oplossing: je complete code in een try/catch blok

[Zoijar]

riezebosch schreef op donderdag 21 juli 2005 @ 11:09:
De oplossing: je complete code in een try/catch blok

Ohja, daar ga je idd van recoveren, en _niet_ abort aanroepen