.Net Exceptions

[mag31]

Is there any way to find out if a particular .net function will throw an
exception without first generating the exception?

I am using structured exception handling i.e. try catch finally blocks with
a top level catch all for Exception. However, I would like to be able to
catch most .net exceptions when they are generated. I would then be able to
generate a valuable exception message and do something about it!!! Hence the
question above.

If anyone would like to talk about their preferred exception handling
methodology I am all ears.

Thanks,
Mark

[Morten Wennevik]

Hi mag31,

To my knowledge, unless the exception is documented somewhere, or you have access to the original source to see what exceptions that method may throw, you have to resort to a general exception catching, catch(Exception ex).

--
Happy Coding!
Morten Wennevik [C# MVP]

[mag31]

Thank you Morten, that answers my question, obviously not with the answer I
want :-(

Mark

"Morten Wennevik" wrote:

Hi mag31,

To my knowledge, unless the exception is documented somewhere, or you have access to the original source to see what exceptions that method may throw, you have to resort to a general exception catching, catch(Exception ex).

--
Happy Coding!
Morten Wennevik [C# MVP]

[cody]

Imho, .NET has a very stupid exception model. There is not way telling which
exceptions can be thrown by a specifiy method. Also the Exception hirarchy
seems not to be well designed.

Lots of people keep telling you that using catch (Exception) is bad style
and you should always catch specific exception Iam the opinion that in some
places is the the best method. Especially when calling third party
components or wrapped winapi stuff like Process.Start or creating Database
connections, you never know which kind of exception can be thrown.
Even if exceptions are documented there a chance that something was
forgotten to document or in a later version a new exception is thrown in
that component or maybe you forget to catch one specific exception.

Sure, if you call int.Parse() you will certainly only catch FormatException
or when reading from a file there will nothing else be thrown except
IOException. But as I said sometimes its better to catch System.Exception,
just to be sure.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk
"mag31" <ma***@discussions.microsoft.com> schrieb im Newsbeitrag
news:F2**********************************@microsof t.com...

Is there any way to find out if a particular .net function will throw an
exception without first generating the exception?

I am using structured exception handling i.e. try catch finally blocks with a top level catch all for Exception. However, I would like to be able to
catch most .net exceptions when they are generated. I would then be able to generate a valuable exception message and do something about it!!! Hence the question above.

If anyone would like to talk about their preferred exception handling
methodology I am all ears.

Thanks,
Mark

[Joerg Jooss]

cody wrote:

Imho, .NET has a very stupid exception model. There is not way
telling which exceptions can be thrown by a specifiy method. Also the
Exception hirarchy seems not to be well designed.
I disagree on the model part, but regarding the hierarchy you're right.
What's really missing is a distinction between potentially recoverable
conditions and irrecoverable failures -- lo and behold, that's what
Exception and Error in Java represent. In defense of MS, getting an
excpetion hierarchy right is incredibly hard -- but since they borrowed so
many good things from Java, they should taken that part as well ;-)

And this is not the same as the SystemException vs. ApplicationException
approach, which doesn't cut it anyway.
Lots of people keep telling you that using catch (Exception) is bad
style and you should always catch specific exception Iam the opinion
that in some places is the the best method.
No. When you say catch (Exception) you think it means:

"This stupid API isn't properly documented, so I need to be sure."

But what it means is

"I can handle it."

Unfortunately, nothing could more mistaken. Depending on the failure, you
may hide or swallow a severe problem. Of course that's caused by the missing
distinction between Error and Exception. But save for a global "log and
die/abort" exception handler, there's little you can do with catch
(Exception).
Especially when calling
third party components or wrapped winapi stuff like Process.Start or
creating Database connections, you never know which kind of exception
can be thrown.
Can you give an example?
Even if exceptions are documented there a chance that something was
forgotten to document or in a later version a new exception is thrown
in that component or maybe you forget to catch one specific exception.
First, hopefully nobody drops an updated library in production without prior
testing. Grab the library, run your unit tests (which hopefully cover both
normal and exptected error conditions), and check the green light. If your
development process doesn't include this very basic step, you're in trouble
anyway...
Sure, if you call int.Parse() you will certainly only catch
FormatException or when reading from a file there will nothing else
be thrown except IOException. But as I said sometimes its better to
catch System.Exception, just to be sure.

To be sure of what ;-)

Cheers,

--
Joerg Jooss
jo*********@gmx.net

[cody]

> > Imho, .NET has a very stupid exception model. There is not way

telling which exceptions can be thrown by a specifiy method. Also the
Exception hirarchy seems not to be well designed.
I disagree on the model part, but regarding the hierarchy you're right.
What's really missing is a distinction between potentially recoverable
conditions and irrecoverable failures -- lo and behold, that's what
Exception and Error in Java represent. In defense of MS, getting an
excpetion hierarchy right is incredibly hard -- but since they borrowed so
many good things from Java, they should taken that part as well ;-)

And this is not the same as the SystemException vs. ApplicationException
approach, which doesn't cut it anyway.

Lots of people keep telling you that using catch (Exception) is bad
style and you should always catch specific exception Iam the opinion
that in some places is the the best method.

No. When you say catch (Exception) you think it means:

"This stupid API isn't properly documented, so I need to be sure."

But what it means is

"I can handle it."

Yes indeed. If I try to start a process with Process.Start() and an
exception occures who cares what kind of error it was? I display a
messagebox and inform the user what happens and display the message from the
exception.
The same is true when trying to open a Database connection or calling a
method which loads a specific file.
The most stupid thing one could do is to catch every exception type that
could possibly occur in an endless stack of catch clauses, each of them
doing the same thing: informing the user and displaying the message of the
exception.
And at the end, an undocumented exception occures which never occured during
testing because it occures because of a wrong driver or similar and this
lets the whole application crash, just because you were soo sure that only
the documented exceptions could occur..
Unfortunately, nothing could more mistaken. Depending on the failure, you
may hide or swallow a severe problem. Of course that's caused by the missing distinction between Error and Exception. But save for a global "log and
die/abort" exception handler, there's little you can do with catch
(Exception).

Especially when calling
third party components or wrapped winapi stuff like Process.Start or
creating Database connections, you never know which kind of exception
can be thrown.

Can you give an example?

You would let your application totally crash just because you third party
sound library throws a funny exception when you tried to play background
sound but the user does have funny hardware which lets the soundcomponent
totally crash. Will you really trust every third party component? You never
should.
Nobody cares wheather the stupid background sounds works or not. But if your
programm crashes because of that you're the stupid.

We *can* trust our own code, sure. But we cannot trust 3rd party components
as we do not have their sourcecode.

--
cody

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

[David Levine]

> I disagree on the model part, but regarding the hierarchy you're right.

What's really missing is a distinction between potentially recoverable
conditions and irrecoverable failures -- lo and behold, that's what
Exception and Error in Java represent.
It isn't at all clear to me how a component that throws an exception can
determine if something is recoverable or not - perhaps there are times it
can, but there are more cases where only a higher-level module can make that
decision.
And this is not the same as the SystemException vs. ApplicationException
approach, which doesn't cut it anyway.
Agreed. On the surface it would be useful to have categories such as
SystemFatalException, SystemCriticalException, but then this opens a
different can of worms - the ability to recover or not from an exception is
application dependent unless the runtime has become corrupted and is about
to shutdown.
No. When you say catch (Exception) you think it means:

"This stupid API isn't properly documented, so I need to be sure."

But what it means is

"I can handle it."

Unfortunately, nothing could more mistaken. Depending on the failure, you
may hide or swallow a severe problem. Of course that's caused by the missing distinction between Error and Exception. But save for a global "log and
die/abort" exception handler, there's little you can do with catch
(Exception).

I have come to use something like this...

catch(SomeSpecificException sse)
{
// recover/retry/whatever
}
catch(Exception ex)
{
throw new CloneExceptionType(ex,"Add some context info here."); // or
throw some other type
}

....and kick it upstairs for high-level code to deal with. Ultimately it
boils down to 2 basic choices - either the code knows how to recover from an
exception or it doesn't. If it doesn't, then you can either allow the user
to retry/cancel/abort the operation, or you can exit the application.


First, hopefully nobody drops an updated library in production without prior testing. Grab the library, run your unit tests (which hopefully cover both
normal and exptected error conditions), and check the green light. If your
development process doesn't include this very basic step, you're in trouble anyway...

I kind of disagree here; I use unit testing and it is a valuable
tool/technique but sometimes all it does is validate our own misconceptions.
It will not force a third-party component to throw exceptions, especially
ones that you did not know could be thrown - if it did then you are really
writing a unit test that validates the component, not your own code. A unit
test would probably create a mock object for the library/component. I think
testing an external component used by your code is more of a systems test
then a unit test.

One problem is how a system evolves over time. Even if you nail it and
handle every specific exception in the original code base, as it evolves and
as components change there is no way to prevent them from throwing exception
types different then those thrown in the original implementation. A robust
system must have some way of dealing with new/unexpected error conditions,
and this forces it to catch and deal with the generic Exception type.

[Joerg Jooss]

cody wrote:

Lots of people keep telling you that using catch (Exception) is bad
style and you should always catch specific exception Iam the opinion
that in some places is the the best method.
No. When you say catch (Exception) you think it means:

"This stupid API isn't properly documented, so I need to be sure."

But what it means is

"I can handle it."

Yes indeed. If I try to start a process with Process.Start() and an
exception occures who cares what kind of error it was? I display a
messagebox and inform the user what happens and display the message
from the exception.

Which depending on the exception may not work.
The same is true when trying to open a Database connection or calling
a method which loads a specific file.
The most stupid thing one could do is to catch every exception type
that could possibly occur in an endless stack of catch clauses, each
of them doing the same thing: informing the user and displaying the
message of the exception.
And at the end, an undocumented exception occures which never occured
during testing because it occures because of a wrong driver or
similar and this lets the whole application crash, just because you
were soo sure that only the documented exceptions could occur..
Again, you're assuming that this is recoverable situation. But in truth, you
don't know if an unexpected exception is recoverable. Also, I don't see the
benefit of an error message saying: "Oops. Dunno what happened, but we'll
continue for now. Stay tuned." A better approach to me is
terminate-and-restart, like the way newer MS Office applications behave.

Unfortunately, nothing could more mistaken. Depending on the
failure, you may hide or swallow a severe problem. Of course that's
caused by the missing distinction between Error and Exception. But
save for a global "log and die/abort" exception handler, there's
little you can do with catch (Exception).

Especially when calling
third party components or wrapped winapi stuff like Process.Start or
creating Database connections, you never know which kind of
exception can be thrown.

Can you give an example?

You would let your application totally crash just because you third
party sound library throws a funny exception when you tried to play
background sound but the user does have funny hardware which lets the
soundcomponent totally crash. Will you really trust every third party
component? You never should.

Again, you only know that *afterwards*, when analyzing a stacktrace. At
runtime, all you can do is keep fingers crossed. A third party library
should not throw "funny" exceptions, but expose a properly designed
exception hierarchy -- otherwise it may do more harm than good.

[...] We *can* trust our own code, sure. But we cannot trust 3rd party
components as we do not have their sourcecode.

That's probably the propert way to look at it from a security perspective,
but from an OO point of view that won't work. Either an exception is part of
a component's accessible API or not. If not, it is an implementation detail
you should not deal with. And can we trust our own code? No. Even our own
code can throw way more exceptions we'll ever be able to handle.

Cheers,

--
Joerg Jooss
jo*********@gmx.net

[cody]

> > Yes indeed. If I try to start a process with Process.Start() and an

exception occures who cares what kind of error it was? I display a
messagebox and inform the user what happens and display the message
from the exception.
Which depending on the exception may not work.

Sure if depends on the component. If it is one of my examples catching all
will work and doesn't cause any problems.
If it throws a fatal exception like stackoverflow, we cannot do anything
anyway since it is rethrown automatically, as are other fatal exceptions
too. Here again is the problem: There is not way telling: do not catch such
fatal exceptions. The .NET exception model is inherently broken. If there
would be at least a property in System.Exception to determine wheather I can
catch that Exception or not, it would be very helpful.
Again, you're assuming that this is recoverable situation. But in truth, you don't know if an unexpected exception is recoverable. Also, I don't see the benefit of an error message saying: "Oops. Dunno what happened, but we'll
continue for now. Stay tuned." A better approach to me is
terminate-and-restart, like the way newer MS Office applications behave.
What is the problem? Fact is that database could not be opened. May it due
to a security issue, an IO-Error, a corrupted database, a denied conection,
a wrong IP or port or driver. Fact is you tell the user why the connection
could not established and tell them to try another database.
Why should we let the whole application crash? If your programs are like
that, I hope I do not need to use them..
Why do you want the whole app to shut down only because "an unknown
exception" occured during connection with the database?

You would let your application totally crash just because you third
party sound library throws a funny exception when you tried to play
background sound but the user does have funny hardware which lets the
soundcomponent totally crash. Will you really trust every third party
component? You never should.

Again, you only know that *afterwards*, when analyzing a stacktrace. At
runtime, all you can do is keep fingers crossed. A third party library
should not throw "funny" exceptions, but expose a properly designed
exception hierarchy -- otherwise it may do more harm than good.

What it should or not is clear, but nevertheless they *can* do it, and you
*cannot* do anything against it.
When your customer comes to you and tells you that your app crashed simply
because of an unknown exception
in a unimportant component of your app crash will you tell them: "oh, but it
should not throw these funny exceptions and therefore I didn't catch them."

We *can* trust our own code, sure. But we cannot trust 3rd party
components as we do not have their sourcecode.

That's probably the propert way to look at it from a security perspective,
but from an OO point of view that won't work. Either an exception is part

of a component's accessible API or not.
The problem is that in .NET unlike java an exception is not part of the
public API.
You can try to document them, but that all you can do: trying it.
If not, it is an implementation detail you should not deal with.
Sure. Let the whole app crash because I should not deal with that exception.

Let me give another example. You have an interface which represents a
database exception. Then you have a method which returns a database
connection (a class which implements that interface).
This database could base upon a network connection, a text file, an excel
file, or it may use remoting.
Sure you can document everything but if somewhere in your exception hirarchy
an exception occures which is not documented you will let you whole app die.
And can we trust our own code? No. Even our own
code can throw way more exceptions we'll ever be able to handle.

In our own code we know which exceptions we throw, we properly document them
and we have strong conventions.

--
cody

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

[Joerg Jooss]

David Levine wrote:

I disagree on the model part, but regarding the hierarchy you're
right. What's really missing is a distinction between potentially
recoverable conditions and irrecoverable failures -- lo and behold,
that's what Exception and Error in Java represent.
It isn't at all clear to me how a component that throws an exception
can determine if something is recoverable or not - perhaps there are
times it can, but there are more cases where only a higher-level
module can make that decision.

In Java, Errors are (to be) only thrown by the JVM. Don't confuse
recoverable with being able to handle. If a component throws an Exception,
it obviously cannot handle it -- but the situation can be recovered from.

And this is not the same as the SystemException vs.
ApplicationException approach, which doesn't cut it anyway.

Agreed. On the surface it would be useful to have categories such as
SystemFatalException, SystemCriticalException, but then this opens a
different can of worms - the ability to recover or not from an
exception is application dependent unless the runtime has become
corrupted and is about to shutdown.

That's why I'd like to see a different exception family that doesn't blur
the lines between a fatal system failure and some recoverable exception.

[...]

No. When you say catch (Exception) you think it means:

"This stupid API isn't properly documented, so I need to be sure."

But what it means is

"I can handle it."

Unfortunately, nothing could more mistaken. Depending on the
failure, you may hide or swallow a severe problem. Of course that's
caused by the missing distinction between Error and Exception. But
save for a global "log and die/abort" exception handler, there's
little you can do with catch (Exception).

I have come to use something like this...

catch(SomeSpecificException sse)
{
// recover/retry/whatever
}
catch(Exception ex)
{
throw new CloneExceptionType(ex,"Add some context info here."); // or
throw some other type
}

...and kick it upstairs for high-level code to deal with. Ultimately
it boils down to 2 basic choices - either the code knows how to
recover from an exception or it doesn't. If it doesn't, then you can
either allow the user to retry/cancel/abort the operation, or you can
exit the application.

Unfortunately, this could mask an OutOfMemoryException or other terrible
things if the newly thrown exception type is not explicitly meant to be
fatal.

First, hopefully nobody drops an updated library in production
without prior testing. Grab the library, run your unit tests (which
hopefully cover both normal and exptected error conditions), and
check the green light. If your development process doesn't include
this very basic step, you're in trouble anyway...

I kind of disagree here; I use unit testing and it is a valuable
tool/technique but sometimes all it does is validate our own
misconceptions. It will not force a third-party component to throw
exceptions, especially ones that you did not know could be thrown -
if it did then you are really writing a unit test that validates the
component, not your own code. A unit test would probably create a
mock object for the library/component. I think testing an external
component used by your code is more of a systems test then a unit
test.

It probably depends on the level of integration that is covered by the test.
A facade that wraps technical exceptions in business interface exceptions
certainly requires such coverage at the unit level.

One problem is how a system evolves over time. Even if you nail it
and handle every specific exception in the original code base, as it
evolves and as components change there is no way to prevent them from
throwing exception types different then those thrown in the original
implementation. A robust system must have some way of dealing with
new/unexpected error conditions, and this forces it to catch and deal
with the generic Exception type.

I still don't see how ignoring or hiding potentially fatal errors
contributes to robustness. The FCL also provides several callbacks that
allow to be notified of unhandled errors.

Cheers,

--
Joerg Jooss
jo*********@gmx.net

[Joerg Jooss]

cody wrote:
[...]

Again, you're assuming that this is recoverable situation. But in
truth, you don't know if an unexpected exception is recoverable.
Also, I don't see the benefit of an error message saying: "Oops.
Dunno what happened, but we'll continue for now. Stay tuned." A
better approach to me is terminate-and-restart, like the way newer
MS Office applications behave.
What is the problem? Fact is that database could not be opened. May
it due to a security issue, an IO-Error, a corrupted database, a
denied conection, a wrong IP or port or driver. Fact is you tell the
user why the connection could not established and tell them to try
another database.

You seem to have a very specific application im mind. Unfortunately, in many
applications selecting another database is not an option. And the whole
sample seems a bit contrived to me. You're not telling me that you handle
database errors by catch (Exception)?
Why should we let the whole application crash? If your programs are
like that, I hope I do not need to use them..
Why do you want the whole app to shut down only because "an unknown
exception" occured during connection with the database?
It's not about letting an application deliberately crash. It's about
avoiding more fatal errors and potential damage to user data as early as
possible.

You would let your application totally crash just because you third
party sound library throws a funny exception when you tried to play
background sound but the user does have funny hardware which lets
the soundcomponent totally crash. Will you really trust every third
party component? You never should.

Again, you only know that *afterwards*, when analyzing a stacktrace.
At runtime, all you can do is keep fingers crossed. A third party
library should not throw "funny" exceptions, but expose a properly
designed exception hierarchy -- otherwise it may do more harm than
good.

What it should or not is clear, but nevertheless they *can* do it,
and you *cannot* do anything against it.

Yeah, sure. I guess they won't complain when you say "no thanks" the next
time they try to sell you a component.
When your customer comes to you and tells you that your app crashed
simply because of an unknown exception
in a unimportant component of your app crash will you tell them: "oh,
but it should not throw these funny exceptions and therefore I didn't
catch them."
You seem to have quite knowledgeable customers ;-)
Again, you're reasoning is based on the flawed assumption you can do
something meaningful with catch (Exception). Just thinking of
OutOfMemoryException, ExecutionEngineException, or StackOverflowException, I
tend to disagree.

We *can* trust our own code, sure. But we cannot trust 3rd party
components as we do not have their sourcecode.

That's probably the propert way to look at it from a security
perspective, but from an OO point of view that won't work. Either an
exception is part of a component's accessible API or not.

The problem is that in .NET unlike java an exception is not part of
the public API.

It is. The compiler cannot enforce it, but it is.
You can try to document them, but that all you can do: trying it.

If not, it is an implementation detail you should not deal with.

Sure. Let the whole app crash because I should not deal with that
exception.

Again, you're confusing crashing with safely aborting. That does not
necessarily imply termination.
Let me give another example. You have an interface which represents a
database exception. Then you have a method which returns a database
connection (a class which implements that interface).
This database could base upon a network connection, a text file, an
excel file, or it may use remoting. Sure you can document everything but if somewhere in your exception
hirarchy an exception occures which is not documented you will let
you whole app die.

And can we trust our own code? No. Even our own
code can throw way more exceptions we'll ever be able to handle.

In our own code we know which exceptions we throw, we properly
document them and we have strong conventions.

You know what your code *explicitly* throws.

Cheers,

--
Joerg Jooss
jo*********@gmx.net

[cody]

> It's not about letting an application deliberately crash. It's about

avoiding more fatal errors and potential damage to user data as early as
possible.
I don't talk about exceptions in my application, Iam talking about 3rd party
components.
If that component throws I know that something is wrong with that component
but this doesn't nessarily mean that my app is in trouble.

If my code, which really deals with user data throws an unknown exception,
in that case my app is in trouble and I'll vertainly not catch
System.Exception, instead shut it down and inform the use about the reason.
Again, you're reasoning is based on the flawed assumption you can do
something meaningful with catch (Exception). Just thinking of
OutOfMemoryException, ExecutionEngineException, or StackOverflowException, I tend to disagree.
That is the whole problem with the .NET exception model. You cannot tell
wheather an exception is critical or not. If you catch one of them, the are
automatically rethrown which means the MessageBox which should inform the
user is displayed and later the global handler will also catch the same
exception and will display a message again.
Yeah, sure. I guess they won't complain when you say "no thanks" the next
time they try to sell you a component.
Yes next time. After the Customer decides not to buy your app because it
crashed just because an unimportant library you used didn't work properly
and threw an unexpected exception.
Again, you're confusing crashing with safely aborting. That does not
necessarily imply termination.

in my knowledge there is no much difference between aborting and
termination.

--
cody

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

[Joerg Jooss]

cody wrote:

It's not about letting an application deliberately crash. It's about
avoiding more fatal errors and potential damage to user data as
early as possible.
I don't talk about exceptions in my application, Iam talking about
3rd party components.
If that component throws I know that something is wrong with that
component but this doesn't nessarily mean that my app is in trouble.

An unhandled exception thrown in third party component is an exception in
your application. If you expect the exception, then you're not in trouble.
But the whole discussion is about blindly handling unknown (i.e. unexpected)
exceptions.
If my code, which really deals with user data throws an unknown
exception, in that case my app is in trouble and I'll vertainly not
catch System.Exception, instead shut it down and inform the use about
the reason.
So we actually agree...

Again, you're reasoning is based on the flawed assumption you can do
something meaningful with catch (Exception). Just thinking of
OutOfMemoryException, ExecutionEngineException, or
StackOverflowException, I tend to disagree.

That is the whole problem with the .NET exception model. You cannot
tell wheather an exception is critical or not.

(I wouldn't call it the model -- it's the exception hierarchy.)
If you catch one of
them, the are automatically rethrown which means the MessageBox which
(Huh?)
should inform the user is displayed and later the global handler will
also catch the same exception and will display a message again.

.... and end up at looking back at Java's Error vs Exception distinction.

Yeah, sure. I guess they won't complain when you say "no thanks" the
next time they try to sell you a component.

Yes next time. After the Customer decides not to buy your app because
it crashed just because an unimportant library you used didn't work
properly and threw an unexpected exception.

It's just that the unimportant library (if it's unimportant, why is it in
there anyway?) might throw OutOfMemoryException. And what will your customer
tell you if your app crashes at later point in time and users lose data,
only because you swallowed a fatal error?

Again, you're confusing crashing with safely aborting. That does not
necessarily imply termination.

in my knowledge there is no much difference between aborting and
termination.

Read again: *Safely* aborting. Logging. Office-style restarting. Overwriting
security sensitive data in memory (unmanaged code). Sending notifications.

Cheers,

--
Joerg Jooss
jo*********@gmx.net

[David Levine]

>

In Java, Errors are (to be) only thrown by the JVM. Don't confuse
recoverable with being able to handle. If a component throws an Exception,
it obviously cannot handle it -- but the situation can be recovered from.
That still does not strike me as a distinction that is always meaningful;
see below for more. Also, I prefer to not get into an argument about JAVA
and .net - frankly, I don't care what java does. If you wish to propose
changing the .net model then please do so without muddying the discussion
with a comparison of .net versus java.

On the surface it would be useful to have categories such as
SystemFatalException, SystemCriticalException, but then this opens a
different can of worms - the ability to recover or not from an
exception is application dependent unless the runtime has become
corrupted and is about to shutdown.

That's why I'd like to see a different exception family that doesn't blur
the lines between a fatal system failure and some recoverable exception.

My perspective is that there is only a single exception that should always
be fatal - ExecutionEngineException - and that is because the runtime itself
has become corrupted; I regard this exception as a form of CLR
self-diagnostic exception.

All other exceptions could be handled by the application, including
StackOverflow, OutOfMemory, etc. The fact that today these are fatal (the
runtime shuts down) does not mean that they always should be fatal. A
managed host ought to be able to establish an secure execution environment
for managed executables/components, perhaps in a secondary appdomain, and a
part of that environment ought to be policies on how these exceptions are
handled. A stack overflow on a manual thread ought to kill the thread but
not necessarily shutdown the entire application; same for OOM. It may
require the appdomain to be unloaded, but it should not require the entire
managed application to terminate.

I have come to use something like this...

catch(SomeSpecificException sse)
{
// recover/retry/whatever
}
catch(Exception ex)
{
throw new CloneExceptionType(ex,"Add some context info here."); // or
throw some other type
}

...and kick it upstairs for high-level code to deal with. Ultimately
it boils down to 2 basic choices - either the code knows how to
recover from an exception or it doesn't. If it doesn't, then you can
either allow the user to retry/cancel/abort the operation, or you can
exit the application.

Unfortunately, this could mask an OutOfMemoryException or other terrible
things if the newly thrown exception type is not explicitly meant to be
fatal.

It would not be masked. The original exception is preserved as the inner
exception, and the same type could be rethrown if that was the intended
effect. Also, the distinction between what is fatal and what is recoverable
is application-dependent.

I once tried to come up with a table of exceptions that were fatal versus
recoverable and add that to my exception handling, but after testing it I
gave up. The reason was simple - if the exception truly is fatal the runtime
will shutdown regardless of what your exception handler does. Typically your
handler will never even get called - the runtime shuts itself down
immediately. This behavior may change in the future and if it does I will
revisit this issue.

This is an area of the runtime that is extremely poorly documented, probably
because the implementation is rapidly changing. If MSFT ever documents the
behavior I can code for it, but until then it seems pointless to try to
second guess the runtime.


It probably depends on the level of integration that is covered by the test. A facade that wraps technical exceptions in business interface exceptions
certainly requires such coverage at the unit level.

re: the manner of unit testing code - a layer that wraps-rethrows
exceptions - is to create a mock object and have a specific test method in
the mock object throw a specific exception that your own code handles. The
unit test invokes a method in your code that calls into the mock object, not
the actual third-party library. The mock object throws the exception and
your code is supposed to deal with it. The unit test code then verifies that
your code did the right thing with it (whatever the "right thing" is
supposed to do).

At no time was the actual 3rd party library invoked; the test will not test
the 3rd party library for new exception types that it might throw.
Therefore it cannot detect changes to the library.

If your test requires your code to actually make calls into the 3rd party
lib then it is not a unit test, it is a system test. They are not the same
thing.

One problem is how a system evolves over time. Even if you nail it
and handle every specific exception in the original code base, as it
evolves and as components change there is no way to prevent them from
throwing exception types different then those thrown in the original
implementation. A robust system must have some way of dealing with
new/unexpected error conditions, and this forces it to catch and deal
with the generic Exception type.
I still don't see how ignoring or hiding potentially fatal errors
contributes to robustness.

In no case were fatal errors hidden or ignored - that is your own
interpretation, and one that is not always correct. It may be true for your
own application that any unhandled exception is fatal, but that is not
universal for all applications.
The FCL also provides several callbacks that
allow to be notified of unhandled errors.

I am aware of that. I regard all UEs as bugs. IMO all exceptions should be
caught and dealt with somewhere. Third party libs represent a particularly
nasty set of problems because they can start threads themselves and not
catch the exceptions thrown on that hidden thread. This will result in a UE
that cannot be caught by wrapping the thread that the library is invoked on.
The supplier of the lib should be notified of the problem so they can fix
it, but the application still needs to deal with it. In this case the system
response should be under the control of the application -
abort/retry/continue/terminate are all valid responses.

[cody]

> > If you catch one of them, the are automatically rethrown which means the
MessageBox which

(Huh?)
Fatal exceptions like StackOverflow cannot actually caught. If you catch
them, they will rethrow automatically at the end of the catch block.
It's just that the unimportant library (if it's unimportant, why is it in
there anyway?) might throw OutOfMemoryException. And what will your customer tell you if your app crashes at later point in time and users lose data,
only because you swallowed a fatal error?

Did you actually read my previous postings? A component for playing
backgroundsound isn't important is it, but you use it the app. If it throws
an unexpected OutOfMemoryException because the soundfile you chose for
playing background sound and throws an unexpected OutOfMemoryException you
would close the application leaving the user no choice. Why? What kind of
Exception this component might throw - it does not affect - and should not
affect the rest of your application.

The next time the app will be started and the app would try to play the same
wavefile again it will crash again, so what now?
Instead you should have told the user that an unknwown problem occured
during load of the wavefile and let him choose another file. You should
never trust a 3rd party component that it throws only the specified
exceptions.

With your attitude, a not 100% correctly working plugin would always crash
(or shutdown if you like that more) the whole application. Why? There is
absolutely no reason for it.
Today, things are changing more and more rapidly and apps are larger and
complexer than ever - and one of the worst things you can do is relying on
every components of your app are working 100% correct.
The more paraniod you are, the better.

--
cody

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

[Joerg Jooss]

David Levine wrote:

In Java, Errors are (to be) only thrown by the JVM. Don't confuse
recoverable with being able to handle. If a component throws an
Exception, it obviously cannot handle it -- but the situation can be
recovered from.
That still does not strike me as a distinction that is always
meaningful; see below for more.

Um... it should be pretty obvious. You won't accidentally catch (swallow,
surpress) fatal errors.
Also, I prefer to not get into an
argument about JAVA and .net - frankly, I don't care what java does.
Ignorance is bliss?
If you wish to propose changing the .net model then please do so
without muddying the discussion with a comparison of .net versus java.
The inherent problem is that the FCL's exception hierarchy is screwed up
(Jeffrey Richter wrote about it back in '02). I'm not muddying the
discussion, I'm referring to a *simple* system that has worked astonglishly
well for quite a few people.

That's why I'd like to see a different exception family that doesn't
blur the lines between a fatal system failure and some recoverable
exception.

My perspective is that there is only a single exception that should
always be fatal - ExecutionEngineException - and that is because the
runtime itself has become corrupted; I regard this exception as a
form of CLR self-diagnostic exception.

All other exceptions could be handled by the application, including
StackOverflow, OutOfMemory, etc. The fact that today these are fatal
(the runtime shuts down) does not mean that they always should be
fatal.

Then we need new exception types. You cannot simply change the semantics of
an exception like that unless your code is meant *not* to be backward
compatible.

[...]

I have come to use something like this...

catch(SomeSpecificException sse)
{
// recover/retry/whatever
}
catch(Exception ex)
{
throw new CloneExceptionType(ex,"Add some context info here."); //
or throw some other type
}

...and kick it upstairs for high-level code to deal with. Ultimately
it boils down to 2 basic choices - either the code knows how to
recover from an exception or it doesn't. If it doesn't, then you can
either allow the user to retry/cancel/abort the operation, or you
can exit the application.

Unfortunately, this could mask an OutOfMemoryException or other
terrible things if the newly thrown exception type is not explicitly
meant to be fatal.

It would not be masked. The original exception is preserved as the
inner exception, and the same type could be rethrown if that was the
intended effect.

Maybe disguising is better a term than "masking", but the problem is that
even if you advise calling code to check inner exceptions explicitly, a
potentially fatal exception remains hidden initially. In my experience,
inner exceptions are rarely checked (just logged), but YMMV.
Also, the distinction between what is fatal and what
is recoverable is application-dependent.
Everything that makes the run-time bail out is fatal by default. That's the
"Error" category. These are the ones I'd like to see out of the mainstream
exception hierarchy.
I once tried to come up with a table of exceptions that were fatal
versus recoverable and add that to my exception handling, but after
testing it I gave up. The reason was simple - if the exception truly
is fatal the runtime will shutdown regardless of what your exception
handler does. Typically your handler will never even get called - the
runtime shuts itself down immediately. This behavior may change in
the future and if it does I will revisit this issue.
But there is the danger of delaying a severe problem to a later point in
time that makes an application failure much more unpleasant than an
immediate termination.

[...]

It probably depends on the level of integration that is covered by
the test. A facade that wraps technical exceptions in business
interface exceptions certainly requires such coverage at the unit
level.

re: the manner of unit testing code - a layer that wraps-rethrows
exceptions - is to create a mock object and have a specific test
method in the mock object throw a specific exception that your own
code handles. The unit test invokes a method in your code that calls
into the mock object, not the actual third-party library. The mock
object throws the exception and your code is supposed to deal with
it. The unit test code then verifies that your code did the right
thing with it (whatever the "right thing" is supposed to do).

At no time was the actual 3rd party library invoked; the test will
not test the 3rd party library for new exception types that it might
throw. Therefore it cannot detect changes to the library.

It all depends on the test's implementation. You assume mocking. That's only
good for the facade's public API testing.
If your test requires your code to actually make calls into the 3rd
party lib then it is not a unit test, it is a system test. They are
not the same thing.

Sorry, but what notion of unit testing is that? Most code can't do anything
useful without calling into third party code.

One problem is how a system evolves over time. Even if you nail it
and handle every specific exception in the original code base, as it
evolves and as components change there is no way to prevent them
from throwing exception types different then those thrown in the
original implementation. A robust system must have some way of
dealing with new/unexpected error conditions, and this forces it to
catch and deal with the generic Exception type.

I still don't see how ignoring or hiding potentially fatal errors
contributes to robustness.

In no case were fatal errors hidden or ignored - that is your own
interpretation, and one that is not always correct. It may be true
for your own application that any unhandled exception is fatal, but
that is not universal for all applications.

See above. Inner exceptions are well disguised, and you require the caller
to check explicity.

Cheers,

--
Joerg Jooss
jo*********@gmx.net

[cody]

> I still don't see how ignoring or hiding potentially fatal errors

contributes to robustness.

I just had a look into the Rotor source. It seems that ms i using catch
(System.Exception) not to sparingly.
I found it in 1.307 files.
The funny things is, that mostly it was trivial stuff like this which made
even me wonder:

try
{
s = c.ToString();
b = Byte.Parse(s, NumberStyles.HexNumber);
}
catch (Exception)
{
String.Format(Environment.GetResourceString("Remot ing_SOAPInteropxsdInvalid"
), "xsd:hexBinary", value);
}

But after revisiting the docs, I found that the Parse method can throw lots
of stuff:

ArgumentNullException
ArgumentException
FormatException.
OverflowException

Who would catch all that stuff everytime he parses a number? This shows us
again the broken exception model of .NET. Let me explain why:
Parse() is a static method and does not depend on a specific state on an
object or the system. Therefore the behaviour of this only method only
depends on it Arguments (Except due to an error in the .NET framework but
then your app would be in big trouble anyway).

I also have to wonder why FormatException does not derive from
ArgumentException?
The same problem with RankException and IndexOutOfRangeException with also
should derive from ArgumentException.

Iam also the opinion that int.Parse() should not throw OverflowException,
instead it should wrap that exception and throw something derived from
ArgumentException or ArgumentOutOfRangeException

--
cody

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

[Joerg Jooss]

cody wrote:

If you catch one of them, the are automatically rethrown which
means the MessageBox which
(Huh?)

Fatal exceptions like StackOverflow cannot actually caught. If you
catch them, they will rethrow automatically at the end of the catch
block.

Trick question: Is that a specified or an observed behaviour?

It's just that the unimportant library (if it's unimportant, why is
it in there anyway?) might throw OutOfMemoryException. And what will
your customer tell you if your app crashes at later point in time
and users lose data, only because you swallowed a fatal error?

Did you actually read my previous postings? A component for playing
backgroundsound isn't important is it, but you use it the app. If it
throws an unexpected OutOfMemoryException because the soundfile you
chose for playing background sound and throws an unexpected
OutOfMemoryException you would close the application leaving the user
no choice. Why? What kind of Exception this component might throw -
it does not affect - and should not affect the rest of your
application.

You seem to live in a world of god applications with optional fancy stuff
that may break. Well, if the DAL of a 3-tiered web application bails out,
you better turn the whole thing off before users continue to type in data
that is destined to die in ether...
The next time the app will be started and the app would try to play
the same wavefile again it will crash again, so what now?
Instead you should have told the user that an unknwown problem occured
during load of the wavefile and let him choose another file. You
should never trust a 3rd party component that it throws only the
specified exceptions.

With your attitude, a not 100% correctly working plugin would always
crash (or shutdown if you like that more) the whole application. Why?
There is absolutely no reason for it.
You still don't get the notion of safely aborting, do you? If an app could
not load a third party component because of unknown exception, it could try
to disable it and restart with the component disabled. If the module is a
core component, the app must remain down, unless you like flogging a dead
horse.
Today, things are changing more and more rapidly and apps are larger
and complexer than ever - and one of the worst things you can do is
relying on every components of your app are working 100% correct.
The more paraniod you are, the better.

Hm... wasn't it me who wrote you cannot trust any code at all ;-)

Cheers,

--
Joerg Jooss
jo*********@gmx.net

[David Levine]

>

Um... it should be pretty obvious. You won't accidentally catch (swallow,
surpress) fatal errors.

Um...if the exception is fatal to the system you cannot swallow it;
otherwise it wouldn't be fatal. And
it should be pretty obvious for other exceptions, ones that are not fatal to
the system, what one application considers fatal might be non-fatal to
another.

Also, I prefer to not get into an
argument about JAVA and .net - frankly, I don't care what java does.

Ignorance is bliss?

No, it is because those discussions usually wander into a statements of
religious belief, not engineering, and from there into immature name
calling. It should be possible to discuss issues in a neutral manner.
The inherent problem is that the FCL's exception hierarchy is screwed up
(Jeffrey Richter wrote about it back in '02).
Got a link? I've read just about everything he has written, and I do not
know which article you are referring to. I recall one complaint he had about
a misleading exception when invoking a method via reflection, and it turns
out he was wrong.
I'm not muddying the
discussion, I'm referring to a *simple* system that has worked astonglishly well for quite a few people.
Simply asserting that a system works well does not prove it. Some systems
work well for small systems but do not scale at all to large systems, nor do
they necessarily evolve well.

There are many limitations in the exception handling implementation in the
current version of .net; attempting to distinguish between a fatal system
error versus all others is one that is way down the list of items of
importance.

That's why I'd like to see a different exception family that doesn't
blur the lines between a fatal system failure and some recoverable
exception.

see below. Basically, if your application can run (i.e. the runtime is not
comprised) then it is recoverable.

Then we need new exception types. You cannot simply change the semantics of an exception like that unless your code is meant *not* to be backward
compatible.

You are conflating many separate issues; adding new exception types does not
solve the problem. Modifying the exception hierarchy will not solve the
problem either. If it is a fatal system error then you are so hosed there is
little the application can do - the runtime usually crashes shortly
thereafter. There would be no value would in adding a few new exception
types.

For all other exceptions, if the integrity of the system has not been
comprised then by definition the exception is not fatal. It may be that the
application may be corrupted, but that would be the fault of the
application, not the system, and one that I would consider to be a bug in
the application.

If you are concerned that an exception has corrupted the application, which
is certainly a valid concern, then there should be a means of detecting that
condition, reporting it, and acting on it. This is entirely application
specific. However, this is not a condition that the runtime will have
knowledge of.


It would not be masked. The original exception is preserved as the
inner exception, and the same type could be rethrown if that was the
intended effect.

Maybe disguising is better a term than "masking", but the problem is that
even if you advise calling code to check inner exceptions explicitly, a
potentially fatal exception remains hidden initially. In my experience,
inner exceptions are rarely checked (just logged), but YMMV.

Actually, I never advise that the inner exception should be checked - I
advise against it. However, it is possible to clone the exception type, wrap
the original and throw a new one of the same type. This allows the code to
add context information without changing the technical reason for the
exception. One can also rethrow the original exception, which is similar to
not catching it at all, but this also does not provide a means of adding
context information.

Also, the distinction between what is fatal and what
is recoverable is application-dependent.

Everything that makes the run-time bail out is fatal by default. That's

the "Error" category. These are the ones I'd like to see out of the mainstream
exception hierarchy.
If the runtime bails out you are done anyway - it typically will not let you
do anything of importance, and it may not even allow the catch handler to
run. I see little value in adding more exceptions that explicitly mean that
the runtime is corrupted.

I once tried to come up with a table of exceptions that were fatal
versus recoverable and add that to my exception handling, but after
testing it I gave up. ...

But there is the danger of delaying a severe problem to a later point in
time that makes an application failure much more unpleasant than an
immediate termination.

The runtime usually halts immediately so nothing will propagate to a later
time because there is no later time. Even if it did, if the runtime's
integrity has been compromised I would not want it to run anyway - it may do
more damage then not running will do. I would rather the runtime terminate
immediately then run the risk of corrupting additional data.

It all depends on the test's implementation. You assume mocking. That's only good for the facade's public API testing.

That is one type of unit test, but not the only one - you can unit test any
method, not just public APIs. A unit test tests a code unit, not the the
external code that it uses.
Sorry, but what notion of unit testing is that? Most code can't do anything useful without calling into third party code.
Again, that is a system test, not a unit test. At some level you may assume
that some libraries (e.g. BCL) are constant and are part of the unit, but I
certainly would not make that assumption with a 3rd party library,
especially one that may generate side-effects.

See above. Inner exceptions are well disguised, and you require the caller
to check explicity.

Not at all - you misinterpreted what I wrote.

Cheers,

[Joerg Jooss]

David Levine wrote:

Um... it should be pretty obvious. You won't accidentally catch
(swallow, surpress) fatal errors.

Um...if the exception is fatal to the system you cannot swallow it;
otherwise it wouldn't be fatal.

I'm thinking of cases where the runtime doesn't immediately go down and the
problem lingers for some time, e.g. because of the famous catch (Exception).
A simple test for example shows that OutOfMemoryExceptions is not fatal in
the sense that the CLR goes down. But once you run into it, you're in
trouble. The run-of-the-mill business application can do little but recycle.

Also, I prefer to not get into an
argument about JAVA and .net - frankly, I don't care what java does.

Ignorance is bliss?

No, it is because those discussions usually wander into a statements
of religious belief, not engineering, and from there into immature
name calling. It should be possible to discuss issues in a neutral
manner.

Yeah, but in the same spirit it should be possible to point out working
alternatives. I don't think anybody has acted like a zealot in the
discussion so far. But don't get me started on checked exceptions. Evil!
Evil! ;-) ;-)

The inherent problem is that the FCL's exception hierarchy is
screwed up (Jeffrey Richter wrote about it back in '02).

Got a link? I've read just about everything he has written, and I do
not know which article you are referring to. I recall one complaint
he had about a misleading exception when invoking a method via
reflection, and it turns out he was wrong.

It's in his book .NET Framework Programming, and some of his comments are
reprinted in the .NET Framework Standard Library Annotated Reference (aka
SLAR).

I'm not muddying the
discussion, I'm referring to a *simple* system that has worked
astonglishly well for quite a few people.

Simply asserting that a system works well does not prove it. Some
systems work well for small systems but do not scale at all to large
systems, nor do they necessarily evolve well.

Sounds a bit academic to me. We're not talking about same fantasy technology
that nobody has ever used. Adding a distinct exception hierarchy for system
failures doesn't change anything fundamentally. Concerns regarding
scalability are a bit farfetched IMHO.
There are many limitations in the exception handling implementation
in the current version of .net; attempting to distinguish between a
fatal system error versus all others is one that is way down the list
of items of importance.
What's on the top of the list?
see below. Basically, if your application can run (i.e. the runtime
is not comprised) then it is recoverable.
Run maybe. Continue to do something meaninful? It depends.

Then we need new exception types. You cannot simply change the
semantics of an exception like that unless your code is meant *not*
to be backward compatible.

You are conflating many separate issues; adding new exception types
does not solve the problem. Modifying the exception hierarchy will
not solve the problem either. If it is a fatal system error then you
are so hosed there is little the application can do - the runtime
usually crashes shortly thereafter. There would be no value would in
adding a few new exception types.

This is all based on the assumption that a fatal exception immediately
forces the system to go down. As long as this is not guaranteed or
specified, I'd rather see a simple mechanism in place that makes sure
developers don't produce potentially harmful code. And even if all this
wasn't required, the value of having a consistent exception type hierarchy
should be obvious.
For all other exceptions, if the integrity of the system has not been
comprised then by definition the exception is not fatal. It may be
that the application may be corrupted, but that would be the fault of
the application, not the system, and one that I would consider to be
a bug in the application.
If you are concerned that an exception has corrupted the application,
which is certainly a valid concern, then there should be a means of
detecting that condition, reporting it, and acting on it. This is
entirely application specific. However, this is not a condition that
the runtime will have knowledge of.
I totally agree. But right now, it means to catch (Exception) or install an
error handler with the unpleasant side effect that what I *may* catch a time
bomb, and I *may* handle it inappropriately.

[...]

Also, the distinction between what is fatal and what
is recoverable is application-dependent.

Everything that makes the run-time bail out is fatal by default.
That's the "Error" category. These are the ones I'd like to see out
of the mainstream exception hierarchy.

If the runtime bails out you are done anyway - it typically will not
let you do anything of importance, and it may not even allow the
catch handler to run. I see little value in adding more exceptions
that explicitly mean that the runtime is corrupted.

It doesn't need to be new types -- all I want are types that are part of
distinct type family.

[...]

It all depends on the test's implementation. You assume mocking.
That's only good for the facade's public API testing.

That is one type of unit test, but not the only one - you can unit
test any method, not just public APIs.

That's what I implied -- testing the internals of a wrapper is one example,
and mocking this would be plain wrong in this case.
A unit test tests a code unit,
not the the external code that it uses.

And if the whole purpose of a code unit is to wrap third party code?

Sorry, but what notion of unit testing is that? Most code can't do
anything useful without calling into third party code.

Again, that is a system test, not a unit test. At some level you may
assume that some libraries (e.g. BCL) are constant and are part of
the unit, but I certainly would not make that assumption with a 3rd
party library, especially one that may generate side-effects.

There's of course a certain level of granularity where a code unit isn't a
unit anymore, but that's a fun story for another discussion.

BTW, a system test to me (i.e. in my company) is a test that exposes the
system to an end user. What you describe would be called an integration
test.

Cheers,

--
Joerg Jooss
jo*********@gmx.net

[cody]

>> Why should user data die if a coponent which has nothing to do with you

user
data throws an Exception?
Maybe it is a visualisation component which throws an Exception for
example
if a number is too large or another specific condition and they never
tested
such a condition.

The error may also be fatal and crash your application at a later point in
time (thus disrupting data). Example: All managed code allocates memory from the managed heap. An OutOfMemoryException even in a non-essential part of
your application is a problem you cannot simply ignore.
Did you read my example with the soundcomponent? If it tries to allocate a
too large soundbuffer, an OutOfMemoryException will occur. But why should
the rest of my application care about that? Since the request to allocate
the large soundbuffer failed, we have still enough memory. We have no
background music playing but we are far far away from trouble.
You may be right in guessing that's a stupid little bug in that component.

You may be wrong,

And if Iam wrong then the App crashes when there is really a problem which
affects vital parts of my app, but in most cases this is not the case.

cody

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

[Joerg Jooss]

cody wrote:

Did you read my example with the soundcomponent? If it tries to
allocate a too large soundbuffer, an OutOfMemoryException will occur.
But why should the rest of my application care about that? Since the
request to allocate the large soundbuffer failed, we have still
enough memory. We have no background music playing but we are far far
away from trouble.

So waht? You still blindly assume that you know that a buffer cannot be
allocated because the allocation size is too big. You just don't know that.
It may be a reasonable assumption in your special case, but that hardly
translates to a general approach.

Cheers,

--
Joerg Jooss
jo*********@gmx.net

[David Levine]

> >

Um...if the exception is fatal to the system you cannot swallow it;
otherwise it wouldn't be fatal.
I'm thinking of cases where the runtime doesn't immediately go down and

the problem lingers for some time, e.g. because of the famous catch (Exception). A simple test for example shows that OutOfMemoryExceptions is not fatal in
the sense that the CLR goes down. But once you run into it, you're in
trouble. The run-of-the-mill business application can do little but recycle. If the runtime has been corrupted but does not shutdown immediately then
there are larger problems then anything the application can deal with.

Even in the example you provide there is no single correct approach that all
applications should use. If the runtime itself is OOM then it will shutdown
regardless of what the app does. If the app is OOM but the system is fine
then there still is no agreed upon course of action that all applications
should follow.

The real problem is that the term "fatal" is ill-defined. Does it refer to
the runtime or to the application? If for the app, then what is fatal for
one app may not be fatal for another, so there could be no agreed upon
exception hierarchy of fatal vs. non-fatal exceptions that would always be
accurate. If it refers to the runtime then if it truly is fatal I would want
the runtime to stop immediately.

Yeah, but in the same spirit it should be possible to point out working
alternatives. I don't think anybody has acted like a zealot in the
discussion so far. But don't get me started on checked exceptions. Evil!
Evil! ;-) ;-)
I am opposed to checked exceptions for a variety of reasons - no point in
getting off-topic. If you have an approach that is of value then please
describe it.

The inherent problem is that the FCL's exception hierarchy is
screwed up (Jeffrey Richter wrote about it back in '02).
Got a link? I've read just about everything he has written, and I do
not know which article you are referring to. I recall one complaint
he had about a misleading exception when invoking a method via
reflection, and it turns out he was wrong.

It's in his book .NET Framework Programming, and some of his comments are
reprinted in the .NET Framework Standard Library Annotated Reference (aka
SLAR).

Why not repeat the gist of it here?

Sounds a bit academic to me. We're not talking about same fantasy technology that nobody has ever used. Adding a distinct exception hierarchy for system failures doesn't change anything fundamentally. Concerns regarding
scalability are a bit farfetched IMHO.
I disagree with both satements. As tempting as it sounds I don't see how
creating this hierarchy adds enough value to justify it. Perhaps you are not
concerned with scalability, but I would be very concerned if the CLR
architects were not.

There are many limitations in the exception handling implementation
in the current version of .net; attempting to distinguish between a
fatal system error versus all others is one that is way down the list
of items of importance.
What's on the top of the list?

Tools (Design time):
Static and dynamic analysis tools to determine the exceptions that can be
thrown from a given method call (I am not referring to checked exceptions).
These ought to be added to an Intellisense list.

There is no way to express the relationship between where an exception is
thrown and where the exception will be handled other then by manually
examining the entire program for all throw and catch statements. This
makes it very difficult to detect missing catch blocks, or places where the
exception is handled in the "wrong" place. In a large system there tends to
be an explosion of handlers with no easy way to manage it.

Distinguish between handling an exception and swallowing an exception - this
ought to generate a compiler warning; I admit this would be difficult to
accurately detect.

Runtime wish list:
Notifications when exceptions are thrown (I believe this was added to the
2.0 version).

Programmatic ability to capture the parameters and locals within a method
when an exception occurs (for logging). Debuggers do this - there ought to
be a module that allows us to do it.

Support for restartable exceptions (low on the wish list).

Theoretical work on when to catch and when to throw.
Currently the guidelines are so poorly defined it is difficult to agree
on a framework that everyone can agree on. Admonishments like "only throw in
exceptional conditions" are pointless and silly - one person's exception is
another's error code - as are "only catch when you can recover". The
guidelines also usually ignore aspects such as boundary-crossings,
distinctions between libraries and applications, server-side versus
client-side differences, etc.


This is all based on the assumption that a fatal exception immediately
forces the system to go down. As long as this is not guaranteed or
specified, I'd rather see a simple mechanism in place that makes sure
developers don't produce potentially harmful code. And even if all this
wasn't required, the value of having a consistent exception type hierarchy
should be obvious.
This is a catch22 - any exception that is fatal to the system is fatal; if
it is not fatal to the system then it is not fatal. If the system does not
realize that it is fatal, then it cannot provide a hierarchy that is
meaningful. It also isn't at all obvious what such a hierarchy would look
like or how it would be used.

I especially don't want the system to keep running if it knows it just hit a
fatal error - at that point it cannot guarantee anything - type safety goes
out the window, as do its guarantees about safe memory access, code access
security, etc.

If the runtime bails out you are done anyway - it typically will not
let you do anything of importance, and it may not even allow the
catch handler to run. I see little value in adding more exceptions
that explicitly mean that the runtime is corrupted.

It doesn't need to be new types -- all I want are types that are part of
distinct type family.

There is a category, not well defined, called SystemException. However,
these are non-fatal and are recoverable by the application. I suspect this
is as close as you will get to what you are looking for. I don't even see
much value in this hierarchy but it is there if you want to use it.

A unit test tests a code unit,
not the the external code that it uses.

And if the whole purpose of a code unit is to wrap third party code?

It doesn't matter - a unit test only tests your code, not external code.

One reason is that unit tests can be run as part of an automated build
process. Build machines should be pristine pure and unpolluted with
application specific binaries that could potentially corrupt the build (IOW,
don't install app executables). If the unit test actually required external
binaries/libraries to function then it could not be made part of the
automated build process. It would especially be a problem if the same build
machine was used for different versions of the app, where each version
required different versions of external components to be installed.

Another reason is that a unit test is intended to validate the assumptions
your code makes, not the actual implementation of the external component.
The mock object simulates the external component and the results you get
from the unit test is as good as your simulation is. If the simulation does
not reflect the reality of the component then your model is incorrect. As I
said, all this does is validate your misconceptions; running a system test
that actually exercises the external component may detect this.

[Joerg Jooss]

David Levine wrote:
[...]

Yeah, but in the same spirit it should be possible to point out
working alternatives. I don't think anybody has acted like a zealot
in the discussion so far. But don't get me started on checked
exceptions. Evil! Evil! ;-) ;-)
I am opposed to checked exceptions for a variety of reasons - no
point in getting off-topic. If you have an approach that is of value
then please describe it.

I guess you somehow missed those ;-)

The inherent problem is that the FCL's exception hierarchy is
screwed up (Jeffrey Richter wrote about it back in '02).

Got a link? I've read just about everything he has written, and I do
not know which article you are referring to. I recall one complaint
he had about a misleading exception when invoking a method via
reflection, and it turns out he was wrong.

It's in his book .NET Framework Programming, and some of his
comments are reprinted in the .NET Framework Standard Library
Annotated Reference (aka SLAR).

Why not repeat the gist of it here?

After reviewing the text, I should rephrase my statement: His main concern
is not the hierarchy (save for the ApplicationException vs SystemException
issue), but bad exception handling practices in the FCL, namely
catch (Exception) and swallowing
catch (SomeException) and throw Exception
catch (SomeException) and rethrowing a new instance of another, non-wrapping
exception type

Sounds a bit academic to me. We're not talking about same fantasy
technology that nobody has ever used. Adding a distinct exception
hierarchy for system failures doesn't change anything fundamentally.
Concerns regarding scalability are a bit farfetched IMHO.

I disagree with both satements. As tempting as it sounds I don't see
how creating this hierarchy adds enough value to justify it. Perhaps
you are not concerned with scalability, but I would be very concerned
if the CLR architects were not.

That's neither what I said, nor what I meant. Why do think that such a thing
would impair scalability? But see below for another point of view regarding
scalability.

There are many limitations in the exception handling implementation
in the current version of .net; attempting to distinguish between a
fatal system error versus all others is one that is way down the
list of items of importance.

What's on the top of the list?

Tools (Design time):
Static and dynamic analysis tools to determine the exceptions that
can be thrown from a given method call (I am not referring to checked
exceptions). These ought to be added to an Intellisense list.

That sounds nice, but I guess it needs some sort of annotation support using
attributes, doesn't it? Something like [ExpectedException] in NUnit.

[Interesting stuff skipped]

This is all based on the assumption that a fatal exception
immediately forces the system to go down. As long as this is not
guaranteed or specified, I'd rather see a simple mechanism in place
that makes sure developers don't produce potentially harmful code.
And even if all this wasn't required, the value of having a
consistent exception type hierarchy should be obvious.

This is a catch22 - any exception that is fatal to the system is
fatal; if it is not fatal to the system then it is not fatal.
If the system does not realize that it is fatal, then it cannot provide a
hierarchy that is meaningful.
It also isn't at all obvious what such
a hierarchy would look like or how it would be used.

Error vs. Exception seems pretty obvious to me. The Error hierarchy can
remain flat.
I especially don't want the system to keep running if it knows it
just hit a fatal error - at that point it cannot guarantee anything -
type safety goes out the window, as do its guarantees about safe
memory access, code access security, etc.

The point is not that the CLR keeps running when it should not or crashes
unexpectedly. The point is that programmers sometimes do stupid things (like
Richter quoted), especially regarding exception handling -- your own list of
tool improvements includes a lot of things to work around those. Exception
handling is one of the most difficult things to get right, if that's even
possible. The system should make it as hard as possible to do these stupid
things.

To illustrate the difference:

try {
// Dangerous stuff
}
catch (Exception ex) {
//
}

is only a bad practice in C#.

try {
// Dangerous stuff
}
catch (Error er) {
//
}

should raise a lot of questions (in Java) in normal application code --
sure, you can write it and it compiles, but is has the simple,
self-documenting property that this is either some very special case or
plain wrong. Like you suggested, there could (should) be even a compiler
warning for these cases.

In that sense, the system does not scale with my observed average
programming skill distribution in real world projects.

It doesn't need to be new types -- all I want are types that are
part of distinct type family.

There is a category, not well defined, called SystemException.
However, these are non-fatal and are recoverable by the application.
I suspect this is as close as you will get to what you are looking
for. I don't even see much value in this hierarchy but it is there if
you want to use it.

Absolutely not. SystemException is probably the right name, but it includes
the wrong exceptions ;-)

A unit test tests a code unit,
not the the external code that it uses.

And if the whole purpose of a code unit is to wrap third party code?

It doesn't matter - a unit test only tests your code, not external
code.

Fine -- but that's your definition. There are other notions as well.

Cheers,

--
Joerg Jooss
jo*********@gmx.net

[Bob Gusek]

"mag31" wrote:

Is there any way to find out if a particular .net function will throw an
exception without first generating the exception?

I am using structured exception handling i.e. try catch finally blocks with
a top level catch all for Exception. However, I would like to be able to
catch most .net exceptions when they are generated. I would then be able to
generate a valuable exception message and do something about it!!! Hence the
question above.

If anyone would like to talk about their preferred exception handling
methodology I am all ears.

Thanks,
Mark

Personally I like using the exception management block. It allows you to
trap exceptions in a consistent format, and is extensible and easy to change
configurations without re-compiling your app.

http://msdn.microsoft.com/library/de...asp?frame=true

I've added a few custom exception publishers, one goes to our bug system and
it's customized to capture all the information our bug system needs.