.NET has a broken Exception model

  • Thread starter Thread starter cody
  • Start date Start date
C

cody

public DateTime Value
{
get
{
try
{
return new DateTime(int.Parse(tbYear.Text), int.Parse(tbMonth.Text),
int.Parse(tbDay.Text));
}
catch (FormatException)
{
// do stuff here
}
catch (ArgumentException)
{
// do stuff here
}
catch (OverflowException)
{
// do stuff here
}
}

Since there is no good base class (No, I won't catch System.Exception) 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 SystemExceptions?

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
(InvalidOperation,Argument,Win32,ObjectDisposed).

Please MS, revise your exception model!

If MS cannot handle this, please allow at least a syntax like

catch (ArgumentException,OverflowException,FormatException)
{
}
 
If I understand you correctly, the functionality is already there. You
can
inherit from ApplicationException which is thrown when non-fatal application
errors happen:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfSystemApplicationExceptionClassTopic.asp
Click to expand...


You must be joking, how can I influence which Exceptions are thrown by
int.Parse or Process.Start?

I had a thread some time ago which addressed the same problem:

http://www.dotnet247.com/247reference/msgs/47/236575.aspx
 
Cody:

My apologies, I thought you were referring to application exceptionss but
seeing the code I see your point.
cody said:
If I understand you correctly, the functionality is already there. You can
inherit from ApplicationException which is thrown when non-fatal application
errors happen:
Click to expand...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfSystemApplicationExceptionClassTopic.asp
Click to expand...


You must be joking, how can I influence which Exceptions are thrown by
int.Parse or Process.Start?

I had a thread some time ago which addressed the same problem:

http://www.dotnet247.com/247reference/msgs/47/236575.aspx

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
Click to expand...
 
My apologies, I thought you were referring to application exceptionss but
seeing the code I see your point.
Click to expand...

And? No answers? Hints? Iam starting to hate .NET for this!
 
I don't see a solution to your problem. I in no way want to trivialize it,
but calling one function from each block doesn't seem that inconvenient but
i acknowledge it's a bit more work then your three exception block you
mention specifically. I don't think that the exception model was built with
the presumption that the scenario you describe is how it would be used and
there's a good amount of literature supporting this. However, for the
specific scenario you have, I guess it is rather inconvenient.

Bill
cody said:
My apologies, I thought you were referring to application exceptionss but
seeing the code I see your point.
Click to expand...

And? No answers? Hints? Iam starting to hate .NET for this!

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tkhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
Click to expand...
 
cody said:
public DateTime Value
{
get
{
try
{
return new DateTime(int.Parse(tbYear.Text),
int.Parse(tbMonth.Text), int.Parse(tbDay.Text));
}
catch (FormatException)
{
// do stuff here
}
catch (ArgumentException)
{
// do stuff here
}
catch (OverflowException)
{
// do stuff here
}
}

Since there is no good base class (No, I won't catch
System.Exception) 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 SystemExceptions?

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
(InvalidOperation,Argument,Win32,ObjectDisposed).

Please MS, revise your exception model!

If MS cannot handle this, please allow at least a syntax like

catch (ArgumentException,OverflowException,FormatException)
{
}
Click to expand...

This already exists. For these you would catch SystemException, which is
not System.Exception. Not a perfect solution but probably workable for your
example.

SystemException is thrown by the common language runtime when errors occur
that are nonfatal and recoverable by user programs. These errors result
from failed runtime check (such as an array out-of-bound error), and can
occur during the execution of any method.

For a list of exceptions that Derive from SystemException see
http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemsystemexceptionclasshierarchy.asp.
--
Tom Porterfield
MS-MVP MCE
http://support.telop.org

Please post all follow-ups to the newsgroup only.
 
Tom:

I think his whole point is that System.Exception 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.Exception 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.

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.Exception 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.

Just my two cents.

Bill
 
public DateTime Value
This already exists. For these you would catch SystemException, which is
not System.Exception. Not a perfect solution but probably workable for your
example.

SystemException is thrown by the common language runtime when errors occur
that are nonfatal and recoverable by user programs. These errors result
from failed runtime check (such as an array out-of-bound error), and can
occur during the execution of any method.

For a list of exceptions that Derive from SystemException see
Click to expand...
http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemsystemexceptionclasshierarchy.asp.

Catching SystemException is as stupid as catching Exception because a
SystemException catches also:

System.ExecutionEngineException
System.ArithmeticException
System.InvalidProgramException
System.OutOfMemoryException
System.StackOverflowException

which I do *not* want to catch, almost never.

Look at the Exception hirarchy, and see what sloppy work microsoft has done.
 
I don't see a solution to your problem. I in no way want to trivialize
it,
but calling one function from each block doesn't seem that inconvenient but
i acknowledge it's a bit more work then your three exception block you
mention specifically. I don't think that the exception model was built with
the presumption that the scenario you describe is how it would be used and
there's a good amount of literature supporting this. However, for the
specific scenario you have, I guess it is rather inconvenient.
Click to expand...


The problem is that you never now which kind of exception a method might
throw and you often end up with catching System.Exception because it is
often the safest and simplest way. I cannot understand why the exception
hirarchy isn't designed this way that it separates fatal from nonfatal
exceptions, instead you have all exception cluttered together in a way that
is beyond any comprehension:

http://msdn.microsoft.com/library/d...f/html/frlrfsystemexceptionclasshierarchy.asp

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
My apologies, I thought you were referring to application exceptionss but
seeing the code I see your point.
Click to expand...

And? No answers? Hints? Iam starting to hate .NET for this!

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
If I understand you correctly, the functionality is already there. You
can
inherit from ApplicationException which is thrown when non-fatal
application
errors happen:
Click to expand...
Click to expand...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
Click to expand...
 
I think his whole point is that System.Exception 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.Exception 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.
Click to expand...

Indeed! You got the Point!
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.Exception 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.
Click to expand...

The problem is that specifications/implementations of components/libraries
you're using can change.
How can you be sure that you take care of *all* Exceptions? There is no way
catching all nonfatal Exceptions, and catching the fatal ones only in a
application defined handler.
 
Catching SystemException is as stupid as catching Exception because a
SystemException catches also:

System.ExecutionEngineException
System.ArithmeticException
System.InvalidProgramException
System.OutOfMemoryException
System.StackOverflowException

which I do *not* want to catch, almost never.

Look at the Exception hirarchy, and see what sloppy work microsoft has done.
Click to expand...

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 very
difficult, if not impossible, to come up with a single hierarchy that worked
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 the
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 burden
on developers.

For all these reasons, and more, I believe the designers punted and just
told us to make the exception hierarchy wide but not deep.

IMO the evolution of tools that can do static analysis to predict exception
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 number
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.Exception). 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. Because
of this the runtime cannot enforce consistency and correctness. I don't want
a Java style checked-exception because it is too constraining, but what we
have now is too wide open.

IMO this is a difficult problem to solve.

Dave L
 
Hi Cody

You could try this:

try {
return new DateTime(int.Parse(tbYear.Text), int.Parse(tbMonth.Text), int.Parse(tbDay.Text));
}
catch (Exception e) {

if ( ((e as FormatException) != null) || ((e as ArgumentException) != null) || ((e as OverflowException) != 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 OutOfMemoryException, for example).

Also, VB.NET has exception filtering, not unlike how you described below.

Hope that helps!
-Chris

--------------------
Reply-To: "cody" <[email protected]>
From: "cody" <[email protected]>
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: <#[email protected]>
Newsgroups: microsoft.public.dotnet.general
NNTP-Posting-Host: jendata.cravi.de 213.238.41.40
Path: cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.general:133578
X-Tomcat-NG: microsoft.public.dotnet.general

public DateTime Value
{
get
{
try
{
return new DateTime(int.Parse(tbYear.Text), int.Parse(tbMonth.Text),
int.Parse(tbDay.Text));
}
catch (FormatException)
{
// do stuff here
}
catch (ArgumentException)
{
// do stuff here
}
catch (OverflowException)
{
// do stuff here
}
}

Since there is no good base class (No, I won't catch System.Exception) 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 SystemExceptions?

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
(InvalidOperation,Argument,Win32,ObjectDisposed).

Please MS, revise your exception model!

If MS cannot handle this, please allow at least a syntax like

catch (ArgumentException,OverflowException,FormatException)
{
}

--
cody

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


--

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.
 
Even simpler, replace
if ( ((e as FormatException) != null) || ((e as ArgumentException) != null) || ((e as OverflowException) != null) ) {
with
if ( (e is FormatException) || (e is ArgumentException) || (e is OverflowException) ) {


-Chris



--------------------
Newsgroups: microsoft.public.dotnet.general
From: (e-mail address removed) ("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.public.dotnet.general
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi Cody

You could try this:

try {
return new DateTime(int.Parse(tbYear.Text), int.Parse(tbMonth.Text), int.Parse(tbDay.Text));
}
catch (Exception e) {

if ( ((e as FormatException) != null) || ((e as ArgumentException) != null) || ((e as OverflowException) != 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 OutOfMemoryException, for example).

Also, VB.NET has exception filtering, not unlike how you described below.

Hope that helps!
-Chris

--------------------
Reply-To: "cody" <[email protected]>
From: "cody" <[email protected]>
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: <#[email protected]>
Newsgroups: microsoft.public.dotnet.general
NNTP-Posting-Host: jendata.cravi.de 213.238.41.40
Path: cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.general:133578
X-Tomcat-NG: microsoft.public.dotnet.general

public DateTime Value
{
get
{
try
{
return new DateTime(int.Parse(tbYear.Text), int.Parse(tbMonth.Text),
int.Parse(tbDay.Text));
}
catch (FormatException)
{
// do stuff here
}
catch (ArgumentException)
{
// do stuff here
}
catch (OverflowException)
{
// do stuff here
}
}

Since there is no good base class (No, I won't catch System.Exception) 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 SystemExceptions?

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
(InvalidOperation,Argument,Win32,ObjectDisposed).

Please MS, revise your exception model!

If MS cannot handle this, please allow at least a syntax like

catch (ArgumentException,OverflowException,FormatException)
{
}

--
cody

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


--

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.
Click to expand...


--

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.
 
"Chris Lyon [MSFT]" said:
Hi Cody

You could try this:

try {
return new DateTime(int.Parse(tbYear.Text),
int.Parse(tbMonth.Text), int.Parse(tbDay.Text));
}
catch (Exception e) {

if ( ((e as FormatException) != null) || ((e as
ArgumentException) != null) || ((e as OverflowException) != 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 OutOfMemoryException, for example).
Click to expand...

That is a good solution, however I would advise using throw; instead of
throw e; in this situation.This should emit a rethrow instruction instead of
a throw instruction, which has different behavior.
Also, VB.NET has exception filtering, not unlike how you described below.
Click to expand...

Yet another reason to want exceptoin filters, ;).
 
Because what is fatal for one is not fatal for another....


cody said:
I don't see a solution to your problem. I in no way want to trivialize it,
but calling one function from each block doesn't seem that inconvenient but
i acknowledge it's a bit more work then your three exception block you
mention specifically. I don't think that the exception model was built with
the presumption that the scenario you describe is how it would be used and
there's a good amount of literature supporting this. However, for the
specific scenario you have, I guess it is rather inconvenient.
Click to expand...


The problem is that you never now which kind of exception a method might
throw and you often end up with catching System.Exception because it is
often the safest and simplest way. I cannot understand why the exception
hirarchy isn't designed this way that it separates fatal from nonfatal
exceptions, instead you have all exception cluttered together in a way that
is beyond any comprehension:

http://msdn.microsoft.com/library/d...f/html/frlrfsystemexceptionclasshierarchy.asp

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
My apologies, I thought you were referring to application
Click to expand...
exceptionss
but
seeing the code I see your point.

And? No answers? Hints? Iam starting to hate .NET for this!

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
If I understand you correctly, the functionality is already there.
You
can
inherit from ApplicationException which is thrown when non-fatal
application
errors happen:
Click to expand...
Click to expand...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/ thrown
by
Click to expand...
Click to expand...
 
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
You could try this:

try {
return new DateTime(int.Parse(tbYear.Text),
Click to expand...
int.Parse(tbMonth.Text), int.Parse(tbDay.Text));
}
catch (Exception e) {

if ( ((e as FormatException) != null) || ((e as
Click to expand...
ArgumentException) != null) || ((e as OverflowException) != null) ) {
// do stuff here
} else {
throw e;
}
}

This will catch all the exceptions in one place, and rethrow anything you
Click to expand...
didn't want to catch (like OutOfMemoryException, for example).
 
Cor Ligthert said:
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?
Click to expand...
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.
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)?
Click to expand...

Can't see any reason OrElse would improve performance, however.
 
Hi Brian,
Can't see any reason OrElse would improve performance, however.
Click to expand...

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
 
Can't see any reason OrElse would improve performance, however.
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?
Click to expand...


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.
 
Back
Top