Hvad er det fede ved Exceptions i .Net?

I .NET bliver du ikke tvunget til at bruge exceptions. Det vil sige du selv kan bestemme om du vil kaste og fange nogen. Problemet er selvfølgelig, at man sagtens kan overbevise sig selv om, at der aldrig vil gå noget galt, og derfor aldrig bruge dem.
Min mening: De er lige så fornuftige at bruge i .NET, som i java. De bliver ikke mindre værd, bare fordi du ikke bliver tvunget til at fange dem.

men hvordan kan jeg være sikker på at jeg har fanget alle exceptions kastet fra 3. partsprodukter? og hvordan kan jeg kaste exceptions og tro at alle min 'kunder' vil fange dem. Jeg betragter exceptions som en måde at beskrive en fejltilstand som programmet måske kan rette op på...  Hvis de ikke bliver fanget vil programmet jo crashe, og det er jeg ikke interesseret i.

Jeg synes det kunne være fedt hvis du henviste til det Microsoft materiale du er uening i.

Du kan fange alle kastede exception med en konstruktion som denne :

try
{
}
catch(Exception)
{
}

Og du har så muligheden for at tage fat i de specifikke som du kan/vil gøre noget ved med

try
{
}
catch(SomeException e)
{
  // hvad du nu kan stille
}
... flere specielle exceptions her
catch(Exception)
{
  // resten
}

Desuden kan du så i din

finally
{
}

gøre hvad der skal gøres for at sikre din applikation.

Jeg forstår ikke helt hvad du mener med at holde sig fra exceptions... De vil blive smidt hvis din kode fejler... Det er vel et spørgsmål om du (programmatisk) sidder i en situation, hvor du synes du har noget mere fornuftigt (en særlig exceptiontype) at fortælle en "caller" om den fejl der er opstået - eller har observerer et forløb som du kan "tillade" dig at kalde en exception selv (altså ikke fremkaldt af en CLR-exception).
Med hensyn til det sidste synes jeg det kan anbefales at være ganske kritisik i sine valg.... Det kan være vældig frustrerende med mange forskellige exceptiontyper, der flyver om ørene på en, med fejlmeddelelser og gode råd - uden egentlig at give noget yderligere end at den oprindelige System.IO.DirectoryNotFoundException, som i mange tilfælde højere oppe i applikationen slet ikke kan betrages som en exception, men blot en oplysning om at en bruger har forsøgt at forespørge på et katalog der ikke findes.... Hvilket i visse applikationstyper kunne være en helt naturlig del af programflowet.

Klart nok vil der også være situationer hvor der går noget galt som man muligvis kan rette op på, men når man skriver koden vil man vanligvis også være godt bekendt med hvad der egentlig kan rettes op runtime, og i den situation vil du så vælge at håndtere den/de specifikke exception(s), som vist i konstruktionen højere oppe.

Men ... nu vil du ikke have links til Microsofts sider - men hvad med et interview med Anders Hejlsberg om emnet. Var det noget ?
http://www.artima.com/intv/handcuffsP.html

Det er bestemt ikke ikke entydigt han taler for checked exceptions... Det er nærmere en konstatering af at de er uenige i den måde det er set implementeret på, men ikke selv har et bedre bud.

Mvh

Du kan ikke være sikker på at fange alle exeptions fra 3.partsprodukter (Eller dine egne for den sags skyld).

Det bedste ville være hvis du selv fangede dine exceptions, så dine kunder blev fri for det. Overvej, om det er nødvendigt for dem at få den exeption, og om du ikke selv kunne gøre noget ved den i stedet. Ellers må du bare dokumentere den, og håbe på det er nok.

For øvrigt... hvis du ikke følger linket, så kan du lige få et link der ligger i forbindelse med interviewet - til en tråd hvor emnet diskuteres udfra artiklen (det er jo selvfølgelig et par du kan finde mange af... altså artikel+tråd parret, men her er da et sted at starte :o)
Mvh

Faktisk er der ikke forskel på C# og Java !

Eller mere præcist: C# exceptions functionality er et subset af Java exception
functionality.

Java har 2 slags exceptions checked exceptions og unchecked exceptions.

Java unchecked exceptions er exceptions som arver fra RuntimeException.

Syntaxen i C# for at fange alle exceptions er:

try
{
  ...
}
catch
{
  ...
}

og svarer til Java:

try
{
  ...
} catch(RuntimeException ex) {
  ...
}

Solid Java kode har også check for runtime exceptions. Og det er derfor
jeg siger at der ikke er nogen forskel.

Man bruger jo også runtime exceptions til noget i Java så selvfølgelig
kan du bruge exceptions i C# til noget.

Det er en nem måde at ryge langt tilbage i call stack'en på.

Når jeg har lavet små værktøjer, og gerne vil fange ALLE exceptions inden de når til slutbrugeren, så plejer jeg at gøre følgende i .net/C#

I min applikations entry, hvor programmet starter, eller evt. som det første i en dll, indsætter jeg en try{}catch{} som sørger for at logge alle fejl og, når det er muligt, oversætte fejl meddelelsen til noget, som jeg mener at slutbrugeren vil kunne forholde sig til, i værste fald noget alá: "Der opstod en ukendt fejl. Tryk 'ok' for at genstarte programmet - du vil ikke miste de data du arbejdede med da fejlen opstod. Fortsætter fejlen kan du gemme dine data inden programmet afsluttes." i stedet for diverse skumle .net exceptions.

Eks. på ovenstående i en winforms applikation:

static void Main()
{
try
{
Application.Run(new MyForm());
}
catch(Exception ex)
{
// Gør noget
}
}

Der er en forholdsvis seriøs gennemgang af checked versus unchecked diskussionen for
Java her:
  http://www-106.ibm.com/developerworks/java/library/j-jtp05254.html

(og Joshua Bloch og Rod Johnsen er 2 kloge mennesker)

Jeg er godt klar over hvordan exceptions fungerer i .Net. Hvad jeg ikke er klar over er hvordan jeg skal kunne bruge det til noget fornuftigt i min dagligdag.

Jeg er ikke enig med Anders Hejlsberg. Hans årsager er til at ikke ville have checked exception er min årsag til at ville have det...  Jeg vil netop gerne have at vide hvis der kommer nye exception, som jeg ikke håndterer.
Hans scalerings eksempel kan jeg ikke helt tage stilling til.

Jeg synes desuden at det er nogle rigtigt dårlige eksempler de kommer med. De skriver at programører sender alle exceptions videre og at de definerer alle metoder til at smide "Exception" for at omgås checked exceptions. Jeg er ikke sikker på at jeg endnu har set sådan kode.

afslutningen på arne_v's artikel giver mig mere lyst til at bruge checked exceptions. Der står at når man bruger unchecked exceptions er det vigtigt at dokumentere det...  Og når man kalder en metode der bruger unchecked exceptions skal man læse dokumentationen for metoden. Forskellen på unchecked og checked exceptions er at checked exceptions med garanti er dokumenterede, og at compileren kan læse dokumentationen og minde én om at fange den exception.

Jeg er doven af natur, og jeg kan ikke se det fede i at skulle finde ud af en masse selv, når det er noget min compiler kunne gøre for mig. Det er vel også derfor at jeg gerne vi have nogle fif til denne trælse manuelle process.

Du får næppe MS til at indføre checked exceptions i C#, så du må nok
lære at leve med det.

Du må læse dokumentation og catche de exceptions som du kan se kan blive smidt
og som du vil catche.

Du må catche Exception på et yderst niveau ligesom du i Java ville catche
RuntimeException for at fange det som nu smuttede igennem af uforudsete
ting.

Du har stadig stor nytte af exceptions. Det er en yderst elegant måde at
hoppe 10 eller 20 eller 30 niveauer tilbage i call stack'en. At kode det
samme med fejl flag og test på disse giver absolut ikke køn kode.

Bemærk at hvis du vil være helt sikker på at håndtere alle exceptions i alle situationer, så kan du benyttes Application.OnThreadException - hvis en exception "bobler" helt op, så fyres dette event... derved kan du undgå at brugerne får en eller anden kryptisk fejlbesked...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWindowsFormsApplicationClassOnThreadExceptionTopic.asp

Tid at få afsluttet spørgsmålet ?

Og et svar såfremt nogle af mine kommentarer har været nyttige

herfra også - i samme ånd :o)

.. jeg vil da også gerne støtte op ;)

runesoft ?

ja, sorry...  Jeg har været væk fra computeren et stykke tid.

Jeg føler dog ikke helt at jeg har fået hvad jeg søgte efter.

Svaret er vel t du har mulighed for at catche exceptions i .NET ligesom du har
mulighed for at catche unchecked exceptions i Java. Det kan nogen gange
gøre koden meget pænere at bruge exceptions end status koders der skal
testes på hele vejen tilbage i kalde stakken. Men man må selv læse
dokumentationen om hvad der kan blive smidt. C++ er iøvrigt lige sådan.