.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.Exceptio n,
just to be sure.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk
"mag31" <ma***@discussi ons.microsoft.c om> schrieb im Newsbeitrag
news:F2******** *************** ***********@mic rosoft.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. ApplicationExce ption
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.Exceptio n, 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. ApplicationExce ption
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. ApplicationExce ption
approach, which doesn't cut it anyway.
Agreed. On the surface it would be useful to have categories such as
SystemFatalExce ption, SystemCriticalE xception, 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(SomeSpeci ficException sse)
{
// recover/retry/whatever
}
catch(Exception ex)
{
throw new CloneExceptionT ype(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.Exceptio n 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.
ApplicationExce ption approach, which doesn't cut it anyway.

Agreed. On the surface it would be useful to have categories such as
SystemFatalExce ption, SystemCriticalE xception, 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(SomeSpeci ficException sse)
{
// recover/retry/whatever
}
catch(Exception ex)
{
throw new CloneExceptionT ype(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 OutOfMemoryExce ption 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