.NET has a broken Exception model

[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,FormatExcepti on)
{
}

--
cody

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

[William Ryan eMVP]

Cody:

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/de...us/cpref/html/
frlrfSystemApplicationExceptionClassTopic.asp

HTH,

Bill
www.devbuzz.com
www.knowdotnet.com

"cody" <no****************@gmx.net> wrote in message
news:#i**************@TK2MSFTNGP12.phx.gbl...

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,FormatExcepti on)
{
}

--
cody

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

[cody]

> 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/de...us/cpref/html/ frlrfSystemApplicationExceptionClassTopic.asp

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/247referenc...47/236575.aspx

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[William Ryan eMVP]

Cody:

My apologies, I thought you were referring to application exceptionss but
seeing the code I see your point.
"cody" <pl*************************@gmx.de> wrote in message
news:Ok*************@TK2MSFTNGP10.phx.gbl...

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/de...us/cpref/html/

frlrfSystemApplicationExceptionClassTopic.asp

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/247referenc...47/236575.aspx

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[cody]

> My apologies, I thought you were referring to application 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 "cody" <pl*************************@gmx.de> wrote in message
news:Ok*************@TK2MSFTNGP10.phx.gbl...

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/de...us/cpref/html/ frlrfSystemApplicationExceptionClassTopic.asp

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/247referenc...47/236575.aspx

[William Ryan eMVP]

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" <pl*************************@gmx.de> wrote in message
news:Ow**************@TK2MSFTNGP11.phx.gbl...

My apologies, I thought you were referring to application 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

"cody" <pl*************************@gmx.de> wrote in message
news:Ok*************@TK2MSFTNGP10.phx.gbl...

> 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/de...us/cpref/html/

> frlrfSystemApplicationExceptionClassTopic.asp
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/247referenc...47/236575.aspx

[Tom Porterfield]

cody wrote:

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,FormatExcepti on)
{
}

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...shierarchy.asp.
--
Tom Porterfield
MS-MVP MCE
http://support.telop.org

Please post all follow-ups to the newsgroup only.

[William Ryan eMVP]

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
"Tom Porterfield" <tp******@mvps.org> wrote in message
news:uH***************@tk2msftngp13.phx.gbl...

cody wrote:

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,FormatExcepti on)
{
}
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...shierarchy.asp. --
Tom Porterfield
MS-MVP MCE
http://support.telop.org

Please post all follow-ups to the newsgroup only.

[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,FormatExcepti on)
{
}
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...shierarchy.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.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[cody]

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

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/de...shierarchy.asp

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk news:Ow**************@TK2MSFTNGP11.phx.gbl...

My apologies, I thought you were referring to application 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

"cody" <pl*************************@gmx.de> wrote in message
news:Ok*************@TK2MSFTNGP10.phx.gbl...
> > 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/de...us/cpref/html/

> > frlrfSystemApplicationExceptionClassTopic.asp
>
>
> 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/247referenc...47/236575.aspx

[AlexS]

Because what is fatal for one is not fatal for another....
"cody" <pl*************************@gmx.de> wrote in message
news:eL**************@TK2MSFTNGP10.phx.gbl...

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.

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/de...shierarchy.asp
--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

news:Ow**************@TK2MSFTNGP11.phx.gbl...

> My apologies, I thought you were referring to application 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
> "cody" <pl*************************@gmx.de> wrote in message
> news:Ok*************@TK2MSFTNGP10.phx.gbl...
> > > 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/de...us/cpref/html/

> > > frlrfSystemApplicationExceptionClassTopic.asp
> >
> >
> > 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/247referenc...47/236575.aspx

[cody]

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

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.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

cody wrote:

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,FormatExcepti on)
{
}

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...shierarchy.asp.

--
Tom Porterfield
MS-MVP MCE
http://support.telop.org

Please post all follow-ups to the newsgroup only.

[Dave]

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

[Chris Lyon [MSFT]]

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" <no****************@gmx.net>
From: "cody" <no****************@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: <#i**************@TK2MSFTNGP12.phx.gbl>
Newsgroups: microsoft.public.dotnet.general
NNTP-Posting-Host: jendata.cravi.de 213.238.41.40
Path: cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFT NGP08.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,FormatExcepti on)
{
}

--
cody

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

--

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.

[Daniel O'Connell [C# MVP]]

""Chris Lyon [MSFT]"" <cl***@online.microsoft.com> wrote in message
news:tf**************@cpmsftngxa10.phx.gbl...

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).
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.
Yet another reason to want exceptoin filters, ;).

Hope that helps!
-Chris

--------------------

Reply-To: "cody" <no****************@gmx.net>
From: "cody" <no****************@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: <#i**************@TK2MSFTNGP12.phx.gbl>
Newsgroups: microsoft.public.dotnet.general
NNTP-Posting-Host: jendata.cravi.de 213.238.41.40
Path:
cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MS FTNGP08.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,FormatExcepti on)
{
}

--
cody

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

--

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]]

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: cl***@online.microsoft.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.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" <no****************@gmx.net>
From: "cody" <no****************@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: <#i**************@TK2MSFTNGP12.phx.gbl>
Newsgroups: microsoft.public.dotnet.general
NNTP-Posting-Host: jendata.cravi.de 213.238.41.40
Path: cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFT NGP08.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,FormatExcepti on)
{
}

--
cody

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

--

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.

--

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]

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), 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

[Daniel O'Connell [C# MVP]]

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:u9***************@tk2msftngp13.phx.gbl...

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? 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)?

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

[Cor Ligthert]

Hi Brian,

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?

Cor

[cody]

> > 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?

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]

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

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]

> > Look at the Exception hirarchy, and see what sloppy work microsoft has

done.

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.
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)
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.
Thats true, you never know for sure which Exceptions will be thrown.
I don't want
a Java style checked-exception because it is too constraining, but what we
have now is too wide open.
Agreed.
IMO this is a difficult problem to solve.

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)
- ArithmeticException
- NullReference
-ArgumentException
-ArgumentNull
-ArgumentOutOfRange
-IndexOutOfBounds
-FormatException

ApplicationException (expected, nonfatal, common, does not necessarily
indicate a bug, they can for example happen on wrong operations by the user)
-IOException
-InvalidOperationException
-SecurityException
-[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.Exception:

Exception
-FatalException
-ApplicationException
-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]]

"cody" <no****************@gmx.net> wrote in message
news:%2******************@TK2MSFTNGP11.phx.gbl...

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.

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.

Good idea, but rethrowing will loose the stack trace.

--
cody

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

[Daniel O'Connell [C# MVP]]

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:OZ**************@TK2MSFTNGP12.phx.gbl...

Hi Brian,

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?

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

[Daniel O'Connell [C# MVP]]

"cody" <no****************@gmx.net> wrote in message
news:u0**************@TK2MSFTNGP12.phx.gbl...

> Look at the Exception hirarchy, and see what sloppy work microsoft has done.

>

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.

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)

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.

Thats true, you never know for sure which Exceptions will be thrown.

I don't want
a Java style checked-exception because it is too constraining, but what
we
have now is too wide open.

Agreed.

IMO this is a difficult problem to solve.

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)
- ArithmeticException
- NullReference
-ArgumentException
-ArgumentNull
-ArgumentOutOfRange
-IndexOutOfBounds
-FormatException

ApplicationException (expected, nonfatal, common, does not necessarily
indicate a bug, they can for example happen on wrong operations by the
user)
-IOException
-InvalidOperationException
-SecurityException
-[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.Exception:

Exception
-FatalException
-ApplicationException
-SystemException

Now it is a really good Exception Hirarchy!

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
APplicationException 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.
--
cody

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

[Cor Ligthert]

Hi Daniel,

It is the same.

Cor

[Dave]

>

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)

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.

I would make 3 Categories:

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

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.

SystemException (unexpected, nonfatal, normally indicates bugs)
- ArithmeticException
- NullReference
-ArgumentException
-ArgumentNull
-ArgumentOutOfRange
-IndexOutOfBounds
-FormatException

ApplicationException (expected, nonfatal, common, does not necessarily
indicate a bug, they can for example happen on wrong operations by the user) -IOException
-InvalidOperationException
-SecurityException
-[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.Exception:

Exception
-FatalException
-ApplicationException
-SystemException

Now it is a really good Exception Hirarchy!

I don't think you will get wide spread agreement; that's probably why MSFT
has not yet done it.

[Tom Porterfield]

William Ryan eMVP wrote:

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.
Reread what I said. I said SystemException, not System.Exception. There is
a distinct difference. All exceptions inherit from System.Exception.
System.SystemException is the base for non-fatal or recoverable exceptions.
The problem comes in when what one person considers recoverable someone else
may consider fatal.
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.

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]

Absolutely, I did misread it. I really need to slow down ;-). Sorry about
that.
"Tom Porterfield" <tp******@mvps.org> wrote in message
news:Oi*************@TK2MSFTNGP09.phx.gbl...

William Ryan eMVP wrote:

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.
Reread what I said. I said SystemException, not System.Exception. There

is a distinct difference. All exceptions inherit from System.Exception.
System.SystemException is the base for non-fatal or recoverable exceptions. The problem comes in when what one person considers recoverable someone else may consider fatal.

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.

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.

[Stu Smith]

(inline)

"Tom Porterfield" <tp******@mvps.org> wrote in message
news:Oi*************@TK2MSFTNGP09.phx.gbl...

William Ryan eMVP wrote:

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.
Reread what I said. I said SystemException, not System.Exception. There

is a distinct difference. All exceptions inherit from System.Exception.
System.SystemException is the base for non-fatal or recoverable exceptions. The problem comes in when what one person considers recoverable someone else may consider fatal.
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
OutOfMemoryException, ExecutionEngineException, and StackOverflowException.
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, ArgumentException and OverflowException 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.TryParse (cf Double.TryParse) in the
framework, as opposed to a shortcoming of the exception system.

Stu

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.

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.

[cody]

> > 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.
Reread what I said. I said SystemException, not System.Exception. There

is a distinct difference. All exceptions inherit from System.Exception.
System.SystemException is the base for non-fatal or recoverable exceptions. The problem comes in when what one person considers recoverable someone else may consider fatal.

You are wrong. Look at the Exception hirarchy. There is no base-class for
non-fatal exceptions in .NET.
These Exceptions derive from System.SystemException:

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

So catching SystemException catches them also, which is certainly not what
we want.

--
cody

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

[cody]

> > 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)

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.

I would make 3 Categories:

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

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.

SystemException (unexpected, nonfatal, normally indicates bugs)
- ArithmeticException
- NullReference
-ArgumentException
-ArgumentNull
-ArgumentOutOfRange
-IndexOutOfBounds
-FormatException

ApplicationException (expected, nonfatal, common, does not necessarily
indicate a bug, they can for example happen on wrong operations by the user)

-IOException
-InvalidOperationException
-SecurityException
-[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.Exception:

Exception
-FatalException
-ApplicationException
-SystemException

Now it is a really good Exception Hirarchy!

I don't think you will get wide spread agreement; that's probably why MSFT
has not yet done it.

Maybe you cannot classify Exceptions in Fatal/Nonfatal that easily. Forget
about that.

But You will Agree with me that you very rarely want to catch a
StackOverflowException.
An ArgumentException is more common to catch and an IOException belongs to
an absolutely comon thing to catch.

The Point is to classify Exceptions in expected Exceptions and unexpected
Exceptions and very rare Exceptions that never normally should not occur.
so that you safely can catch an ApplicationException (from my
classification) knowing that you only catch exceptions commonly thrown by
methods.

This way, you have a contract: Methods should never throw Exceptions but
those derived from ApplicationException. If another exception occures
(ArithmeticException, NullReference) or similar, you know something is
wrong.

--
cody

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

[cody]

> > Good idea, but rethrowing will loose the stack trace.

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.

Theoretically. But I've read a longer timer ago that this is not the full
truth.
The difference between rethrow and applying ExceptionFilters was the main
argument for the usage of ExceptionFilters but I cannot remember what it
was.
In VS if you are in debug mode, a rethrown Exception won't lead you to the
point where the original Exception was thrown, for example.

--
cody

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

[cody]

OK, maybe fatal or non-fatal is a bit fuzzy. But what about expected and
unexpected? Stackoverflow,Arithmetic, ExecutionEngine-Exceptions are
normally not Expected while IOException is commonly caught.

So I would at least distinguish between expected, unexpected and rare
Exceptions, see my other posts for details.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

Because what is fatal for one is not fatal for another....
"cody" <pl*************************@gmx.de> wrote in message
news:eL**************@TK2MSFTNGP10.phx.gbl...

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.

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/de...shierarchy.asp
--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

news:Ow**************@TK2MSFTNGP11.phx.gbl...
> > My apologies, I thought you were referring to application 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
> > "cody" <pl*************************@gmx.de> wrote in message
> > news:Ok*************@TK2MSFTNGP10.phx.gbl...
> > > > 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/de...us/cpref/html/ > > > > frlrfSystemApplicationExceptionClassTopic.asp
> > >
> > >
> > > 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/247referenc...47/236575.aspx

[cody]

> >> IMO this is a difficult problem to solve.

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)
- ArithmeticException
- NullReference
-ArgumentException
-ArgumentNull
-ArgumentOutOfRange
-IndexOutOfBounds
-FormatException

ApplicationException (expected, nonfatal, common, does not necessarily
indicate a bug, they can for example happen on wrong operations by the
user)
-IOException
-InvalidOperationException
-SecurityException
-[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.Exception:

Exception
-FatalException
-ApplicationException
-SystemException

Now it is a really good Exception Hirarchy!

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
ApplicationException for example, or some which don't fit any of these.
I cannot imagine one. SystemExceptions should be thrown by the CLR while
ApplicationExceptions should be thrown by applictions and libraries.
While I agree that your basic layout is pretty good, I'm not sure it covers everything.

Thank you. While I have something like a layout Iam still trying to figure
out wheather the .NET Exception hirarchy has a structure at all..

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

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

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.

Good idea, but rethrowing will loose the stack trace.

Now I know what the problem with rethrowing was: If I recall correctly,
you'll lose the state of the local variables.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Dave]

>

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
OutOfMemoryException, ExecutionEngineException, and StackOverflowException. You simply can't catch them, except possibly within the unhandled exception handler.

Even these can change, and they probably will. About the only one I can
think of that would always be fatal is ExecutionEngineException as that
indicates that the runtime itself is corrupt. But even these distinctions
are not all that useful because there is high liklihood that if the runtime
itself detected its own internal corruption, as it likely in one of these
three exceptions, it would probably halt its normal exception propagation
and simply terminate the app, so you really couldn't catch it anyway.
Personally, in the case of this thread, I'd say the problem is that there is no Int32.TryParse or DateTime.TryParse (cf Double.TryParse) in the
framework, as opposed to a shortcoming of the exception system.

Stu

there is a double.TryParse, and one of its arguments let's you specify its
type (int, float, etc).

[Dave]

>

Maybe you cannot classify Exceptions in Fatal/Nonfatal that easily. Forget
about that.

But You will Agree with me that you very rarely want to catch a
StackOverflowException.
An ArgumentException is more common to catch and an IOException belongs to
an absolutely comon thing to catch.

Well, as I said earlier, I can forsee a runtime that provides a more robust
environment for running arbitrary code in sandboxes. In this case when such
an exception occurs I might want to terminate an appdomain, but I would not
want exception to be fatal to the entire app unless that was a policy
decision made by the host.

The Point is to classify Exceptions in expected Exceptions and unexpected
Exceptions and very rare Exceptions that never normally should not occur.
so that you safely can catch an ApplicationException (from my
classification) knowing that you only catch exceptions commonly thrown by
methods.

This way, you have a contract: Methods should never throw Exceptions but
those derived from ApplicationException. If another exception occures
(ArithmeticException, NullReference) or similar, you know something is
wrong.

--

I agree with your intent, but the problem is that the current mechanism
really doesn't support, at least not in a generically useful manner, the
type of categorization you want to do. Given the current architecture and
implementation of exceptions it is most useful when the exception hierarchy
is wide but not very deep. As soon as you try to deepen the hierarchy, which
is what trying to classify exceptions into different categories would do,
you run into all sorts of practical problems that I don't believe can be
overcome. You may come up with perfect categories, but it's only perfect for
your usage.

Even though exception objects are fully object oriented by themselves, and
you can create a complex hierarchy based on them, in practice it does not
appear very useful to create such a hierarchy.

I look at it this way...methods identifies its arguments, both input and
output, and the return value, as types, as specified by the method
signature - this constitutes an API contract. One of the problems with
exceptions is that there is no means of specifying an exception contract -
it is fully untyped, even to the point that there really is no guarantee
that only exceptions that derive from System.Exception will be thrown (code
written in IL can throw integers). This makes it backwardly compatible with
Win32, but it imposes limitations as well. You can constrain the code so
that it only deals with a subset of these, in this case limiting the code to
be CLS-compliant so that it only catches types derived from
System.Exception, but the runtime itself is not so constrained.

The fact that the runtime does not enforce a type system on exceptions, and
because there is no exception contract mechanism that can be enforced by the
runtime, means that the only standards that can be applied are those applied
via coding discipline. One of the truths in computing is that any system
that relies on programmer hygiene is doomed - it must be enforced by a
runtime mechanism for it to succeed.

IMO, a better system would involve high-level abstractions so that exception
contracts, or perhaps more generically, an error contract, could be
specified and to have the CLR participate in this. Perhaps I'm the only one
who sees value in such a system, but in the meantime I'll try to make the
best of what I've got to work with and make do until something better comes
along.

[Dave]

"cody" <no****************@gmx.net> wrote in message
news:ee****************@TK2MSFTNGP11.phx.gbl...

Good idea, but rethrowing will loose the stack trace.

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.

Theoretically. But I've read a longer timer ago that this is not the full
truth.
The difference between rethrow and applying ExceptionFilters was the main
argument for the usage of ExceptionFilters but I cannot remember what it
was.
In VS if you are in debug mode, a rethrown Exception won't lead you to the
point where the original Exception was thrown, for example.

--
cody

The difference is really quite simple. The statement

throw e;

will reset the stack trace in exception object "e" so that the stack trace
begins on the same line as the throw statement. The statement:

throw;

will rethrow the original exception object without resetting the stack
trace.

So if you catch an exception, examine and decide you don't really want to
handle it and have nothing of value to add, then simply use
throw;

If you want to erase from the stack trace the original line that generated
the exception (in essence, hide information) then use:

throw e;

If you want to add context (this is usually what I do), then use something
like this:

throw new Exception("What I was doing.",ex);

This preserves the original exception as the inner exception in the
exception object. The difference is that I did not preserve the exception
type, but I could have done that as well had I wanted to.

[cody]

"Dave" <no****************@wi.rr.com> schrieb im Newsbeitrag
news:#E**************@TK2MSFTNGP11.phx.gbl...

Maybe you cannot classify Exceptions in Fatal/Nonfatal that easily. Forget about that.

But You will Agree with me that you very rarely want to catch a
StackOverflowException.
An ArgumentException is more common to catch and an IOException belongs to an absolutely comon thing to catch.

Well, as I said earlier, I can forsee a runtime that provides a more

robust environment for running arbitrary code in sandboxes. In this case when such an exception occurs I might want to terminate an appdomain, but I would not want exception to be fatal to the entire app unless that was a policy
decision made by the host.

The Point is to classify Exceptions in expected Exceptions and unexpected Exceptions and very rare Exceptions that never normally should not occur. so that you safely can catch an ApplicationException (from my
classification) knowing that you only catch exceptions commonly thrown by methods.

This way, you have a contract: Methods should never throw Exceptions but
those derived from ApplicationException. If another exception occures
(ArithmeticException, NullReference) or similar, you know something is
wrong.

--
I agree with your intent, but the problem is that the current mechanism
really doesn't support, at least not in a generically useful manner, the
type of categorization you want to do. Given the current architecture and
implementation of exceptions it is most useful when the exception

hierarchy is wide but not very deep. As soon as you try to deepen the hierarchy, which is what trying to classify exceptions into different categories would do,
you run into all sorts of practical problems that I don't believe can be
overcome. You may come up with perfect categories, but it's only perfect for your usage.

Even though exception objects are fully object oriented by themselves, and
you can create a complex hierarchy based on them, in practice it does not
appear very useful to create such a hierarchy.

I look at it this way...methods identifies its arguments, both input and
output, and the return value, as types, as specified by the method
signature - this constitutes an API contract. One of the problems with
exceptions is that there is no means of specifying an exception contract -
it is fully untyped, even to the point that there really is no guarantee
that only exceptions that derive from System.Exception will be thrown (code written in IL can throw integers). This makes it backwardly compatible with Win32, but it imposes limitations as well. You can constrain the code so
that it only deals with a subset of these, in this case limiting the code to be CLS-compliant so that it only catches types derived from
System.Exception, but the runtime itself is not so constrained.

The fact that the runtime does not enforce a type system on exceptions, and because there is no exception contract mechanism that can be enforced by the runtime, means that the only standards that can be applied are those applied via coding discipline. One of the truths in computing is that any system
that relies on programmer hygiene is doomed - it must be enforced by a
runtime mechanism for it to succeed.

IMO, a better system would involve high-level abstractions so that exception contracts, or perhaps more generically, an error contract, could be
specified and to have the CLR participate in this. Perhaps I'm the only one who sees value in such a system, but in the meantime I'll try to make the
best of what I've got to work with and make do until something better

comes
Are you thinking of something like checked exceptions in Java?
I hated them. They lead to code that is cluttered with try/catch. The
problem is that if the thrown Exceptions are part of the interface for
example "Stream" you do not only have to catch Exceptions in a "FileStream"
but also in a MemoryStream or a ConsoleInputStream which is very annoying in
Java. The problem is that different implementations of an interface will
throw different Exceptions.

In my opinion, there should be a way to specify Exceptions that are thrown
by methods (throws clause), but you should not be forced to catch them.

If you compile with a special compiler parameter, the compiler will force
you to specify every Exception that might be thrown by a method. This leads
to cleaner and more robust code because the programmer of a method has to
think about what exception his methods can throw. At the moment, nobody
knows, what Exceptions a method can throw, even the programmer might not be
aware of all of them.

--
cody

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

[Dave]

>

Are you thinking of something like checked exceptions in Java?

I've said many times that this is not the way to do it. Checked exceptions
were a noble but failed experiment.

[Stu Smith]

"Dave" <no****************@wi.rr.com> wrote in message
news:ef****************@TK2MSFTNGP09.phx.gbl...

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
OutOfMemoryException, ExecutionEngineException, and

StackOverflowException.

You simply can't catch them, except possibly within the unhandled

exception

handler.

Even these can change, and they probably will. About the only one I can
think of that would always be fatal is ExecutionEngineException as that
indicates that the runtime itself is corrupt. But even these distinctions
are not all that useful because there is high liklihood that if the

runtime itself detected its own internal corruption, as it likely in one of these
three exceptions, it would probably halt its normal exception propagation
and simply terminate the app, so you really couldn't catch it anyway.

Personally, in the case of this thread, I'd say the problem is that

there is

no Int32.TryParse or DateTime.TryParse (cf Double.TryParse) in the
framework, as opposed to a shortcoming of the exception system.

Stu
there is a double.TryParse, and one of its arguments let's you specify its
type (int, float, etc).

Yep, that's what I meant. There is a double TryParse, but not one for Int32,
DateTime etc. As such, the OP is having to use exceptions for control-flow
which isn't really exceptional. I think that's the problem, rather than the
exception model.

cf is short for 'confer', which apparently is Latin for compare.

Stu

[cody]

> > Are you thinking of something like checked exceptions in Java?

I've said many times that this is not the way to do it. Checked exceptions
were a noble but failed experiment.

So how do you imagine such an error/exception-contract?

--
cody

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