.NET has a broken Exception model

[Chris Lyon [MSFT]]

RE: .NET has a broken Exception model

Even simpler, replace
if ( ((e as FormatException ) != null) || ((e as ArgumentExcepti on) != null) || ((e as OverflowExcepti on) != null) ) {
with
if ( (e is FormatException ) || (e is ArgumentExcepti on) || (e is OverflowExcepti on) ) {


-Chris



--------------------[color=blue]
>Newsgroups: microsoft.publi c.dotnet.genera l
>From: clyon@online.mi crosoft.com ("Chris Lyon [MSFT]")
>Organization : Microsoft
>Date: Tue, 11 May 2004 00:17:24 GMT
>Subject: RE: .NET has a broken Exception model
>X-Tomcat-NG: microsoft.publi c.dotnet.genera l
>MIME-Version: 1.0
>Content-Type: text/plain
>Content-Transfer-Encoding: 7bit
>
>Hi Cody
>
>You could try this:
>
> try {
> return new DateTime(int.Pa rse(tbYear.Text ), int.Parse(tbMon th.Text), int.Parse(tbDay .Text));
> }
> catch (Exception e) {
>
> if ( ((e as FormatException ) != null) || ((e as ArgumentExcepti on) != null) || ((e as OverflowExcepti on) != null) ) {
> // do stuff here
> } else {
> throw e;
> }
> }
>
>This will catch all the exceptions in one place, and rethrow anything you didn't want to catch (like OutOfMemoryExce ption, for example).
>
>Also, VB.NET has exception filtering, not unlike how you described below.
>
>Hope that helps!
>-Chris
>
>--------------------[color=green]
>>Reply-To: "cody" <no_spam_deutro nium@gmx.net>
>>From: "cody" <no_spam_deutro nium@gmx.net>
>>Subject: .NET has a broken Exception model
>>Date: Mon, 10 May 2004 17:40:29 +0200
>>Lines: 50
>>X-Priority: 3
>>X-MSMail-Priority: Normal
>>X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
>>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
>>Message-ID: <#ij77ZqNEHA.16 16@TK2MSFTNGP12 .phx.gbl>
>>Newsgroups: microsoft.publi c.dotnet.genera l
>>NNTP-Posting-Host: jendata.cravi.d e 213.238.41.40
>>Path: cpmsftngxa10.ph x.gbl!TK2MSFTFE ED01.phx.gbl!TK 2MSFTNGP08.phx. gbl!TK2MSFTNGP1 2.phx.gbl
>>Xref: cpmsftngxa10.ph x.gbl microsoft.publi c.dotnet.genera l:133578
>>X-Tomcat-NG: microsoft.publi c.dotnet.genera l
>>
>>public DateTime Value
>>{
>> get
>> {
>> try
>> {
>> return new DateTime(int.Pa rse(tbYear.Text ), int.Parse(tbMon th.Text),
>>int.Parse(tbD ay.Text));
>> }
>> catch (FormatExceptio n)
>> {
>> // do stuff here
>> }
>> catch (ArgumentExcept ion)
>> {
>> // do stuff here
>> }
>> catch (OverflowExcept ion)
>> {
>> // do stuff here
>> }
>>}
>>
>>Since there is no good base class (No, I won't catch System.Exceptio n) I
>>have to catch all three exceptions separately. If all three exceptions
>>requires the same error handling I have to write the code three times or
>>have to create a separate method only for this stupid small exception
>>handling.
>>
>>Why not one single base-class for all non-fatal SystemException s?
>>
>>There are many other examples, e.g. a simple call to Process.Start which can
>>throw 4 different exceptions which I have to deal with
>>(InvalidOpera tion,Argument,W in32,ObjectDisp osed).
>>
>>Please MS, revise your exception model!
>>
>>If MS cannot handle this, please allow at least a syntax like
>>
>>catch (ArgumentExcept ion,OverflowExc eption,FormatEx ception)
>>{
>>}
>>
>>--
>>cody
>>
>>Freeware Tools, Games and Humour
>>http://www.deutronium.de.vu || http://www.deutronium.tk
>>
>>
>>[/color]
>
>
>--
>
>This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
>http://www.microsoft.com/info/cpyright.htm
>
>Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.
>[/color]


--

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at

http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.

[Cor Ligthert]

Re: .NET has a broken Exception model

Hi Chris,

A nice explanation on this long thread where I was on the hand of Cody.

What do you mean with VB exception filtering, I hope not the On Error?

I assume that the same code you provided will be usable with VB.net too,
where the OrElse will probably even improve the performance (very slightly
of course)?

Cor
[color=blue]
> You could try this:
>
> try {
> return new DateTime(int.Pa rse(tbYear.Text ),[/color]
int.Parse(tbMon th.Text), int.Parse(tbDay .Text));[color=blue]
> }
> catch (Exception e) {
>
> if ( ((e as FormatException ) != null) || ((e as[/color]
ArgumentExcepti on) != null) || ((e as OverflowExcepti on) != null) ) {[color=blue]
> // do stuff here
> } else {
> throw e;
> }
> }
>
> This will catch all the exceptions in one place, and rethrow anything you[/color]
didn't want to catch (like OutOfMemoryExce ption, for example).[color=blue]
>
> Also, VB.NET has exception filtering, not unlike how you described below.
>
> Hope that helps!
> -Chris
>[/color]

[Daniel O'Connell [C# MVP]]

Re: .NET has a broken Exception model


"Cor Ligthert" <notfirstname@p lanet.nl> wrote in message
news:u9AR%232xN EHA.644@tk2msft ngp13.phx.gbl.. .[color=blue]
> Hi Chris,
>
> A nice explanation on this long thread where I was on the hand of Cody.
>
> What do you mean with VB exception filtering, I hope not the On Error?[/color]
VB allows exception handlers to define additional constraints on an
exception, I think it is something like

Catch E As Exception where E.ErrorCode = 500

but don't quote me.
[color=blue]
>
> I assume that the same code you provided will be usable with VB.net too,
> where the OrElse will probably even improve the performance (very slightly
> of course)?[/color]

Can't see any reason OrElse would improve performance, however.

[Cor Ligthert]

Re: .NET has a broken Exception model

Hi Brian,[color=blue]
>
> Can't see any reason OrElse would improve performance, however.
>[/color]

I did not like this statement when I got the first explanations about this
in these newsgroups, because I thought it was an useless addition to the
logical Or in VB.net.

However it is a build in statement like this pseudo

If not a = 1
if not b = 1
if not c = 1

While the logical Or in VB does evaluate all expressions even when one is
false, thinking this over I agree with you that falling down the Catch
statements will be the same. However than it is an addition to use in this
case in VB.net OrElse.

Maybe that is the same behaviour as the C# logical Or || that I do not know.

So when it is, than tell me because now I am curious about it?

Cor

[cody]

Re: .NET has a broken Exception model

> > Can't see any reason OrElse would improve performance, however.[color=blue][color=green]
> >[/color]
>
> I did not like this statement when I got the first explanations about this
> in these newsgroups, because I thought it was an useless addition to the
> logical Or in VB.net.
>
> However it is a build in statement like this pseudo
>
> If not a = 1
> if not b = 1
> if not c = 1
>
> While the logical Or in VB does evaluate all expressions even when one is
> false, thinking this over I agree with you that falling down the Catch
> statements will be the same. However than it is an addition to use in this
> case in VB.net OrElse.
>
> Maybe that is the same behaviour as the C# logical Or || that I do not[/color]
know.[color=blue]
>
> So when it is, than tell me because now I am curious about it?[/color]


The logical || performs a shortcut evaluation, that is it stops if the
result is clear.
In cotrast, the | operator always fully evaluated the whole expression.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

[cody]

Re: .NET has a broken Exception model

> You could try this:[color=blue]
>
> try {
> return new DateTime(int.Pa rse(tbYear.Text ),[/color]
int.Parse(tbMon th.Text), int.Parse(tbDay .Text));[color=blue]
> }
> catch (Exception e) {
>
> if ( ((e as FormatException ) != null) || ((e as[/color]
ArgumentExcepti on) != null) || ((e as OverflowExcepti on) != null) ) {[color=blue]
> // do stuff here
> } else {
> throw e;
> }
> }
>
> This will catch all the exceptions in one place, and rethrow anything you[/color]
didn't want to catch (like OutOfMemoryExce ption, for example).[color=blue]
>
> Also, VB.NET has exception filtering, not unlike how you described below.[/color]


Good idea, but rethrowing will loose the stack trace.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

[cody]

Re: .NET has a broken Exception model

> > Look at the Exception hirarchy, and see what sloppy work microsoft has[color=blue]
> done.[color=green]
> >[/color]
>
> I don't look at the model as being broken or sloppy, it's more that it is
> immature and incomplete. The problem with trying to categorize exceptions
> (and I've thought some about how to do it) is that I think it would be[/color]
very[color=blue]
> difficult, if not impossible, to come up with a single hierarchy that[/color]
worked[color=blue]
> for all the cases. Any such hierarchy would likely lock developers into a
> number of version dependencies that would make it difficult to move the
> framework forward. For example, is StackOverflow fatal? Perhaps it is in[/color]
the[color=blue]
> current rev, but perhaps not in the next one. Perhaps it is fatal on the
> main thread and not on a worker thread. It would be hard to come up with a
> hierarchy that was both meaningful and which did not impose an undue[/color]
burden[color=blue]
> on developers.[/color]

I do not agree. a StackOverflow is fatal, it always was and will always be.
Even if not, you certainly don't want to catch it, especially not accidently
whech catch (Exception)
[color=blue]
> IMO the evolution of tools that can do static analysis to predict[/color]
exception[color=blue]
> types and exception flow will help this. I also believe that there will be
> future languages that more directly attack this problem. There are a[/color]
number[color=blue]
> of problems with using exceptions but I find that it is still far superior
> to using the other common mechanisms, such as sentinel return values.
>
> One of the fundamental problems with the current implementation in .NET is
> that exceptions are very loosely typed (other then it being derived from
> System.Exceptio n). I look at exceptions as a side-band channel for moving
> data back up the call stack, but there is no API contract or definition,
> other then documentation, to define what exception types to expect.[/color]
Because[color=blue]
> of this the runtime cannot enforce consistency and correctness.[/color]

Thats true, you never know for sure which Exceptions will be thrown.
[color=blue]
> I don't want
> a Java style checked-exception because it is too constraining, but what we
> have now is too wide open.[/color]

Agreed.
[color=blue]
> IMO this is a difficult problem to solve.[/color]

Indeed. But I tried it:

I would make 3 Categories:

FatalException (unexpected, fatal, cannot recover, indicates serious bugs)
- StackOverflow
- InvalidProgram,
- OutOfMemory
- ExcutionEngine

SystemException (unexpected, nonfatal, normally indicates bugs)
- ArithmeticExcep tion
- NullReference
-ArgumentExcepti on
-ArgumentNull
-ArgumentOutOfRa nge
-IndexOutOfBound s
-FormatException

ApplicationExce ption (expected, nonfatal, common, does not necessarily
indicate a bug, they can for example happen on wrong operations by the user)
-IOException
-InvalidOperatio nException
-SecurityExcepti on
-[All other exceptions that are based on hardware/OS failures, missing
hardware/OS-features, wrong versions, security issues, user decisions and so
on]

Alle three should be derived from System.Exceptio n:

Exception
-FatalException
-ApplicationExce ption
-SystemException

Now it is a really good Exception Hirarchy!


--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

[Daniel O'Connell [C# MVP]]

Re: .NET has a broken Exception model


"cody" <no_spam_deutro nium@gmx.net> wrote in message
news:%23g%2391s yNEHA.3744@TK2M SFTNGP11.phx.gb l...[color=blue][color=green]
>> You could try this:
>>
>> try {
>> return new DateTime(int.Pa rse(tbYear.Text ),[/color]
> int.Parse(tbMon th.Text), int.Parse(tbDay .Text));[color=green]
>> }
>> catch (Exception e) {
>>
>> if ( ((e as FormatException ) != null) || ((e as[/color]
> ArgumentExcepti on) != null) || ((e as OverflowExcepti on) != null) ) {[color=green]
>> // do stuff here
>> } else {
>> throw e;
>> }
>> }
>>
>> This will catch all the exceptions in one place, and rethrow anything you[/color]
> didn't want to catch (like OutOfMemoryExce ption, for example).[color=green]
>>
>> Also, VB.NET has exception filtering, not unlike how you described below.[/color]
>[/color]
Thats why you should use throw; I think that doesn't change the stack
trace...you'll have to experiment with it to make sure.
[color=blue]
>
> Good idea, but rethrowing will loose the stack trace.
>
> --
> cody
>
> Freeware Tools, Games and Humour
> http://www.deutronium.de.vu || http://www.deutronium.tk
>
>[/color]

[Daniel O'Connell [C# MVP]]

Re: .NET has a broken Exception model


"Cor Ligthert" <notfirstname@p lanet.nl> wrote in message
news:OZIk1OyNEH A.2500@TK2MSFTN GP12.phx.gbl...[color=blue]
> Hi Brian,[color=green]
>>
>> Can't see any reason OrElse would improve performance, however.
>>[/color]
>
> I did not like this statement when I got the first explanations about this
> in these newsgroups, because I thought it was an useless addition to the
> logical Or in VB.net.
>
> However it is a build in statement like this pseudo
>
> If not a = 1
> if not b = 1
> if not c = 1
>
> While the logical Or in VB does evaluate all expressions even when one is
> false, thinking this over I agree with you that falling down the Catch
> statements will be the same. However than it is an addition to use in this
> case in VB.net OrElse.
>
> Maybe that is the same behaviour as the C# logical Or || that I do not
> know.
>
> So when it is, than tell me because now I am curious about it?
>[/color]

|| is pretty much equivilent to OrElse. As cody said it performs a
short-circuted comparison. && is also equivilent to VB's AndAlso, & is Ands
and | is Ors I believe. There might be some subtle differences(I'm not a VB
expert) but they should be pretty close, all in all.
[color=blue]
> Cor
>
>[/color]

[Daniel O'Connell [C# MVP]]

Re: .NET has a broken Exception model


"cody" <no_spam_deutro nium@gmx.net> wrote in message
news:u0FpMyyNEH A.3124@TK2MSFTN GP12.phx.gbl...[color=blue][color=green][color=darkred]
>> > Look at the Exception hirarchy, and see what sloppy work microsoft has[/color]
>> done.[color=darkred]
>> >[/color]
>>
>> I don't look at the model as being broken or sloppy, it's more that it is
>> immature and incomplete. The problem with trying to categorize exceptions
>> (and I've thought some about how to do it) is that I think it would be[/color]
> very[color=green]
>> difficult, if not impossible, to come up with a single hierarchy that[/color]
> worked[color=green]
>> for all the cases. Any such hierarchy would likely lock developers into a
>> number of version dependencies that would make it difficult to move the
>> framework forward. For example, is StackOverflow fatal? Perhaps it is in[/color]
> the[color=green]
>> current rev, but perhaps not in the next one. Perhaps it is fatal on the
>> main thread and not on a worker thread. It would be hard to come up with
>> a
>> hierarchy that was both meaningful and which did not impose an undue[/color]
> burden[color=green]
>> on developers.[/color]
>
> I do not agree. a StackOverflow is fatal, it always was and will always
> be.
> Even if not, you certainly don't want to catch it, especially not
> accidently
> whech catch (Exception)
>[color=green]
>> IMO the evolution of tools that can do static analysis to predict[/color]
> exception[color=green]
>> types and exception flow will help this. I also believe that there will
>> be
>> future languages that more directly attack this problem. There are a[/color]
> number[color=green]
>> of problems with using exceptions but I find that it is still far
>> superior
>> to using the other common mechanisms, such as sentinel return values.
>>
>> One of the fundamental problems with the current implementation in .NET
>> is
>> that exceptions are very loosely typed (other then it being derived from
>> System.Exceptio n). I look at exceptions as a side-band channel for moving
>> data back up the call stack, but there is no API contract or definition,
>> other then documentation, to define what exception types to expect.[/color]
> Because[color=green]
>> of this the runtime cannot enforce consistency and correctness.[/color]
>
> Thats true, you never know for sure which Exceptions will be thrown.
>[color=green]
>> I don't want
>> a Java style checked-exception because it is too constraining, but what
>> we
>> have now is too wide open.[/color]
>
> Agreed.
>[color=green]
>> IMO this is a difficult problem to solve.[/color]
>
> Indeed. But I tried it:
>
> I would make 3 Categories:
>
> FatalException (unexpected, fatal, cannot recover, indicates serious bugs)
> - StackOverflow
> - InvalidProgram,
> - OutOfMemory
> - ExcutionEngine
>
> SystemException (unexpected, nonfatal, normally indicates bugs)
> - ArithmeticExcep tion
> - NullReference
> -ArgumentExcepti on
> -ArgumentNull
> -ArgumentOutOfRa nge
> -IndexOutOfBound s
> -FormatException
>
> ApplicationExce ption (expected, nonfatal, common, does not necessarily
> indicate a bug, they can for example happen on wrong operations by the
> user)
> -IOException
> -InvalidOperatio nException
> -SecurityExcepti on
> -[All other exceptions that are based on hardware/OS failures, missing
> hardware/OS-features, wrong versions, security issues, user decisions and
> so
> on]
>
> Alle three should be derived from System.Exceptio n:
>
> Exception
> -FatalException
> -ApplicationExce ption
> -SystemException
>
> Now it is a really good Exception Hirarchy!
>[/color]

Maybe it is, maybe. Unfortunatly, until you add every existing exception and
make sure there are no conflicts you can't safely define a root hiearchy.
There may be some which could exist in both SystemException and
APplicationExce ption for example, or some which don't fit any of these.
While I agree that your basic layout is pretty good, I'm not sure it covers
everything.[color=blue]
>
> --
> cody
>
> Freeware Tools, Games and Humour
> http://www.deutronium.de.vu || http://www.deutronium.tk
>
>[/color]

[Cor Ligthert]

Re: .NET has a broken Exception model

Hi Daniel,

It is the same.

Cor

[Dave]

Re: .NET has a broken Exception model

>[color=blue]
> I do not agree. a StackOverflow is fatal, it always was and will always[/color]
be.[color=blue]
> Even if not, you certainly don't want to catch it, especially not[/color]
accidently[color=blue]
> whech catch (Exception)
>[/color]

I disagree. Execution engines that run user-defined code (e.g. a plug-in
architecture) should account for buggy code. A good plugin architecture sets
up both a security sandbox and an execution sandbox so that a buggy plugin
does not compromise the entire system.

[color=blue]
> I would make 3 Categories:
>
> FatalException (unexpected, fatal, cannot recover, indicates serious bugs)
> - StackOverflow
> - InvalidProgram,
> - OutOfMemory
> - ExcutionEngine
>[/color]

The only one I would agree with all the time is the ExecutionEngine , and
only because this represents the case where the CLR itself cannot continue.

[color=blue]
> SystemException (unexpected, nonfatal, normally indicates bugs)
> - ArithmeticExcep tion
> - NullReference
> -ArgumentExcepti on
> -ArgumentNull
> -ArgumentOutOfRa nge
> -IndexOutOfBound s
> -FormatException
>
> ApplicationExce ption (expected, nonfatal, common, does not necessarily
> indicate a bug, they can for example happen on wrong operations by the[/color]
user)[color=blue]
> -IOException
> -InvalidOperatio nException
> -SecurityExcepti on
> -[All other exceptions that are based on hardware/OS failures, missing
> hardware/OS-features, wrong versions, security issues, user decisions and[/color]
so[color=blue]
> on]
>
> Alle three should be derived from System.Exceptio n:
>
> Exception
> -FatalException
> -ApplicationExce ption
> -SystemException
>
> Now it is a really good Exception Hirarchy!
>
>[/color]
I don't think you will get wide spread agreement; that's probably why MSFT
has not yet done it.

[Tom Porterfield]

Re: .NET has a broken Exception model

William Ryan eMVP wrote:[color=blue]
> Tom:
>
> I think his whole point is that System.Exceptio n is a lame approach
> but not using it requires quite a bit of code for this situation.
> Take Cody's example directly and say that based on those exceptions,
> he returns lets say a return code of 0. Now, if something more
> severe happens or is outside of the bounds there, say the classic
> OutOfMemory exception, System.Exceptio n is going to catch it and
> return a 0. There would be no differentiation between the two. Do
> this in a class library that you distribute and you could really
> obscure some ugly bugs.[/color]

Reread what I said. I said SystemException , not System.Exceptio n. There is
a distinct difference. All exceptions inherit from System.Exceptio n.
System.SystemEx ception is the base for non-fatal or recoverable exceptions.
The problem comes in when what one person considers recoverable someone else
may consider fatal.
[color=blue]
> Personally in this situation I trap all my exceptions specifically
> and don't really have a problem b/c I seldom do the same things for
> different exceptions (actually, I never do unless it's an oversight)
> so it's not really an issue to me, but if I wanted to trap those four
> things and respond the same way to each of them like he mentions,
> then it would cause you to write some extraneous code. But catching
> System.Exceptio n in an instance like this seems to be the worst of
> all worlds (I mean no offense by this, just MHO). You can't possibly
> know/anticipate and respond specifically to every possible exception
> under the sun and assuming one wanted to make the argument they could
> (mathematically it's possible), you'd defintiely write a lot of code
> that you didn't know.[/color]

No offense taken as you didn't read my original message correctly.

It really depends on what the requirement is. If you only care about four
specific exceptions then you have to filter in some way, either with
distinct catches or a more generic catch and then throw if the exception
isn't what you wanted. Like just about any problem, this one has multiple
solutions, all with their own merit.
--
Tom Porterfield
MS-MVP MCE

http://support.telop.org

Please post all follow-ups to the newsgroup only.

[William Ryan eMVP]

Re: .NET has a broken Exception model

Absolutely, I did misread it. I really need to slow down ;-). Sorry about
that.
"Tom Porterfield" <tpporter@mvps. org> wrote in message
news:OihGex0NEH A.736@TK2MSFTNG P09.phx.gbl...[color=blue]
> William Ryan eMVP wrote:[color=green]
> > Tom:
> >
> > I think his whole point is that System.Exceptio n is a lame approach
> > but not using it requires quite a bit of code for this situation.
> > Take Cody's example directly and say that based on those exceptions,
> > he returns lets say a return code of 0. Now, if something more
> > severe happens or is outside of the bounds there, say the classic
> > OutOfMemory exception, System.Exceptio n is going to catch it and
> > return a 0. There would be no differentiation between the two. Do
> > this in a class library that you distribute and you could really
> > obscure some ugly bugs.[/color]
>
> Reread what I said. I said SystemException , not System.Exceptio n. There[/color]
is[color=blue]
> a distinct difference. All exceptions inherit from System.Exceptio n.
> System.SystemEx ception is the base for non-fatal or recoverable[/color]
exceptions.[color=blue]
> The problem comes in when what one person considers recoverable someone[/color]
else[color=blue]
> may consider fatal.
>[color=green]
> > Personally in this situation I trap all my exceptions specifically
> > and don't really have a problem b/c I seldom do the same things for
> > different exceptions (actually, I never do unless it's an oversight)
> > so it's not really an issue to me, but if I wanted to trap those four
> > things and respond the same way to each of them like he mentions,
> > then it would cause you to write some extraneous code. But catching
> > System.Exceptio n in an instance like this seems to be the worst of
> > all worlds (I mean no offense by this, just MHO). You can't possibly
> > know/anticipate and respond specifically to every possible exception
> > under the sun and assuming one wanted to make the argument they could
> > (mathematically it's possible), you'd defintiely write a lot of code
> > that you didn't know.[/color]
>
> No offense taken as you didn't read my original message correctly.
>
> It really depends on what the requirement is. If you only care about four
> specific exceptions then you have to filter in some way, either with
> distinct catches or a more generic catch and then throw if the exception
> isn't what you wanted. Like just about any problem, this one has multiple
> solutions, all with their own merit.
> --
> Tom Porterfield
> MS-MVP MCE
> http://support.telop.org
>
> Please post all follow-ups to the newsgroup only.
>[/color]

[Stu Smith]

Re: .NET has a broken Exception model

(inline)

"Tom Porterfield" <tpporter@mvps. org> wrote in message
news:OihGex0NEH A.736@TK2MSFTNG P09.phx.gbl...[color=blue]
> William Ryan eMVP wrote:[color=green]
> > Tom:
> >
> > I think his whole point is that System.Exceptio n is a lame approach
> > but not using it requires quite a bit of code for this situation.
> > Take Cody's example directly and say that based on those exceptions,
> > he returns lets say a return code of 0. Now, if something more
> > severe happens or is outside of the bounds there, say the classic
> > OutOfMemory exception, System.Exceptio n is going to catch it and
> > return a 0. There would be no differentiation between the two. Do
> > this in a class library that you distribute and you could really
> > obscure some ugly bugs.[/color]
>
> Reread what I said. I said SystemException , not System.Exceptio n. There[/color]
is[color=blue]
> a distinct difference. All exceptions inherit from System.Exceptio n.
> System.SystemEx ception is the base for non-fatal or recoverable[/color]
exceptions.[color=blue]
> The problem comes in when what one person considers recoverable someone[/color]
else[color=blue]
> may consider fatal.[/color]

It's probably best, to avoid a neverending argument, to distinguish between
two sorts of fatal vs non-fatal:

1) Fatal exceptions as defined by the framework. They are
OutOfMemoryExce ption, ExecutionEngine Exception, and StackOverflowEx ception.
You simply can't catch them, except possibly within the unhandled exception
handler.

2) Fatal within the context of a block of code. So in the current example,
FormatException , ArgumentExcepti on and OverflowExcepti on are being
considered as non-fatal (ie they aren't going to be allowed out of this
stack frame). All other exceptions are outside the scope of that block of
code, and will unwind until some other block of code considers itself
capable of dealing with them.

I tend to use "fatal" for case (1) but I suppose you could use it for case
(2).


Personally, in the case of this thread, I'd say the problem is that there is
no Int32.TryParse or DateTime.TryPar se (cf Double.TryParse ) in the
framework, as opposed to a shortcoming of the exception system.

Stu

[color=blue]
>[color=green]
> > Personally in this situation I trap all my exceptions specifically
> > and don't really have a problem b/c I seldom do the same things for
> > different exceptions (actually, I never do unless it's an oversight)
> > so it's not really an issue to me, but if I wanted to trap those four
> > things and respond the same way to each of them like he mentions,
> > then it would cause you to write some extraneous code. But catching
> > System.Exceptio n in an instance like this seems to be the worst of
> > all worlds (I mean no offense by this, just MHO). You can't possibly
> > know/anticipate and respond specifically to every possible exception
> > under the sun and assuming one wanted to make the argument they could
> > (mathematically it's possible), you'd defintiely write a lot of code
> > that you didn't know.[/color]
>
> No offense taken as you didn't read my original message correctly.
>
> It really depends on what the requirement is. If you only care about four
> specific exceptions then you have to filter in some way, either with
> distinct catches or a more generic catch and then throw if the exception
> isn't what you wanted. Like just about any problem, this one has multiple
> solutions, all with their own merit.
> --
> Tom Porterfield
> MS-MVP MCE
> http://support.telop.org
>
> Please post all follow-ups to the newsgroup only.
>[/color]