when to handle exception

[=?Utf-8?B?UmFq?=]

How do I know which methods will throw exception when I am using FCL or other
third party .Net library?

I am developer of mostly native Windows applications and now .Net. After
working few months in Java, I am thinking why Win32 APIs or even .Net
documentation not clear on which methods will throw exception or what
exceptions can be expected. Jave APIs clearly define exceptions that can be
expected and enforces that we handle them.

Can someone explain Windows philosophy on exception handling? I read lot of
books/help on how to do exception handling but never clearly saw when to do?

Thanks,
Raj

[=?Utf-8?B?S2VyZW0gR8O8bXLDvGtjw7w=?=]

Hi Raj,

on .NET nearly any function/member can throw a
a exceptions and the exception is always derrived
from the Exception base class. This means that you
can encapsulate a possible dangerous function
call with a try/catch as you are used to do with
C/C++/Java, etc,...and catch a "base" exception
and either determine its type and display extra
messane or just show what the Message member
holds for you. It always tells you the reason for
failure.

In case of the Windows Native API, you said
you are fammiliar with, you can mostly (but
not aways!) trust the functions return value
and the GetLastError() function. In Win32
you secure Code Blocks with SEH (Structured
Exception Handling __try/__catch/__finally.

I recommend you to read this for better
understanding:

[.NET Framework Developer's Guide
Exception Handling]
http://msdn.microsoft.com/en-us/library/ms229005.aspx
[.NET Framework Developer's Guide
Handling and Throwing Exceptions]
http://msdn.microsoft.com/en-us/library/5b2yeyab.aspx
Hope this helps and clarifies your darkness a bit,...;-)
Regards

Kerem

--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Latest Project: http://www.codeplex.com/restarts
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."
"Raj" <Ra*@discussions.microsoft.comschrieb im Newsbeitrag
news:82**********************************@microsof t.com...

How do I know which methods will throw exception when I am using FCL or
other
third party .Net library?

I am developer of mostly native Windows applications and now .Net. After
working few months in Java, I am thinking why Win32 APIs or even .Net
documentation not clear on which methods will throw exception or what
exceptions can be expected. Jave APIs clearly define exceptions that can
be
expected and enforces that we handle them.

Can someone explain Windows philosophy on exception handling? I read lot
of
books/help on how to do exception handling but never clearly saw when to
do?

Thanks,
Raj

[sloan]

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!234.entry
Go there, and follow the link to Krzysztof Cwalina's article.

I think it may be the same one listed above (same content, but not on the
microsoft.com site)
And its worth a 3rd, 4th ........... even 10th reading.

.........

"Raj" <Ra*@discussions.microsoft.comwrote in message
news:82**********************************@microsof t.com...

How do I know which methods will throw exception when I am using FCL or
other
third party .Net library?

I am developer of mostly native Windows applications and now .Net. After
working few months in Java, I am thinking why Win32 APIs or even .Net
documentation not clear on which methods will throw exception or what
exceptions can be expected. Jave APIs clearly define exceptions that can
be
expected and enforces that we handle them.

Can someone explain Windows philosophy on exception handling? I read lot
of
books/help on how to do exception handling but never clearly saw when to
do?

Thanks,
Raj

[Peter Duniho]

On Tue, 16 Sep 2008 09:25:02 -0700, Raj <Ra*@discussions.microsoft.com>
wrote:

How do I know which methods will throw exception when I am using FCL or
other
third party .Net library?

You need to ask the author's of such third-party libraries.

Ideally, as is the case for the .NET documentation, they will clearly
document what exceptions may be thrown. But that's up to each individual
author of a library. There's no general rule that will work for all of
them.

I am developer of mostly native Windows applications and now .Net. After
working few months in Java, I am thinking why Win32 APIs or even .Net
documentation not clear on which methods will throw exception or what
exceptions can be expected.

I don't understand the statement. Win32 APIs do not, as a general rule,
throw exceptions. They return errors. .NET APIs do, as a general rule,
throw exceptions on failure, and that is always documented.

Jave APIs clearly define exceptions that can be
expected and enforces that we handle them.

Almost true. The fact is, in Java there are exceptions that are enforced
and those that aren't. Only the ones that are enforced are "clearly
defined" and "enforced that we handle them". So, even in Java you have
the possibility of an exception that's not documented but which could
still be thrown.

That said, if your real question is truly (as your Subject: line suggests)
"when to handle exceptions?", the answer is that you should handle them
when you can do something useful with it. If it makes sense for the
method in which you are considering handling the exception to actually
catch and process the exception, then do so. In the vast majority of
cases, this implies (just as in Java) that the caller of the method will
not ever know about the exception, not even the possibility of the
exception.

In other words, "do something useful with it" is another way of saying
that the method catching the exception can consider itself to have
successfully accomplished its purpose, even if an exception was thrown and
caught during the execution of that method.

If your method can't do something useful with the exception, then don't
catch it.

Can someone explain Windows philosophy on exception handling? I read lot
of
books/help on how to do exception handling but never clearly saw when to
do?

The article that sloan mentions seems to be a reasonable discussion to
me. But, keep in mind that it's more about .NET than about Windows
generally. Windows has evolved over more than two decades and as such is
not going to have a uniform philosophy. It's also more about designing
code that might _throw_ exceptions, rather than being about designing code
that might need to _handle_ exceptions. So it may have limited utility in
the context of your question here.

Pete

[=?Utf-8?B?UmFq?=]

Thanks Kerem, sloan and Peter.

I liked what Peter said - catch exception if you can do something useful
with it. So far I found two reasons of when to catch exception:

1) If we acquired a critical section and if there is a possibility of
exception, catch block can release that critical section.

2) If we modified a shared resource and if there is exception, we can put
that shared resource in a reusable state (for other application process) in a
catch block.
May be this is not a different reason, just a more general case of reason (1).

It will be interesting if you guys can add more reasons where you can catch
exception and do something with it.

Thanks,
Raj


"Peter Duniho" wrote:

On Tue, 16 Sep 2008 09:25:02 -0700, Raj <Ra*@discussions.microsoft.com>
wrote:

How do I know which methods will throw exception when I am using FCL or
other
third party .Net library?

You need to ask the author's of such third-party libraries.

Ideally, as is the case for the .NET documentation, they will clearly
document what exceptions may be thrown. But that's up to each individual
author of a library. There's no general rule that will work for all of
them.

I am developer of mostly native Windows applications and now .Net. After
working few months in Java, I am thinking why Win32 APIs or even .Net
documentation not clear on which methods will throw exception or what
exceptions can be expected.

I don't understand the statement. Win32 APIs do not, as a general rule,
throw exceptions. They return errors. .NET APIs do, as a general rule,
throw exceptions on failure, and that is always documented.

Jave APIs clearly define exceptions that can be
expected and enforces that we handle them.

Almost true. The fact is, in Java there are exceptions that are enforced
and those that aren't. Only the ones that are enforced are "clearly
defined" and "enforced that we handle them". So, even in Java you have
the possibility of an exception that's not documented but which could
still be thrown.

That said, if your real question is truly (as your Subject: line suggests)
"when to handle exceptions?", the answer is that you should handle them
when you can do something useful with it. If it makes sense for the
method in which you are considering handling the exception to actually
catch and process the exception, then do so. In the vast majority of
cases, this implies (just as in Java) that the caller of the method will
not ever know about the exception, not even the possibility of the
exception.

In other words, "do something useful with it" is another way of saying
that the method catching the exception can consider itself to have
successfully accomplished its purpose, even if an exception was thrown and
caught during the execution of that method.

If your method can't do something useful with the exception, then don't
catch it.

Can someone explain Windows philosophy on exception handling? I read lot
of
books/help on how to do exception handling but never clearly saw when to
do?

The article that sloan mentions seems to be a reasonable discussion to
me. But, keep in mind that it's more about .NET than about Windows
generally. Windows has evolved over more than two decades and as such is
not going to have a uniform philosophy. It's also more about designing
code that might _throw_ exceptions, rather than being about designing code
that might need to _handle_ exceptions. So it may have limited utility in
the context of your question here.

Pete

[Jon Skeet [C# MVP]]

Raj <Ra*@discussions.microsoft.comwrote:

Thanks Kerem, sloan and Peter.

I liked what Peter said - catch exception if you can do something useful
with it. So far I found two reasons of when to catch exception:

1) If we acquired a critical section and if there is a possibility of
exception, catch block can release that critical section.

No, a finally block is a much better choice here. You're not actually
doing something useful with the exception - you're doing something
useful just because you're leaving that scope. That's what finally is
for. Catching exceptions is good when you can actually *handle* that
exception - or have some other reason to prevent it from propagating up
the call stack in its current form.

2) If we modified a shared resource and if there is exception, we can put
that shared resource in a reusable state (for other application process) in a
catch block.
May be this is not a different reason, just a more general case of reason (1).

Again, a finally block is better here.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Peter Duniho]

On Tue, 16 Sep 2008 14:45:01 -0700, Raj <Ra*@discussions.microsoft.com>
wrote:

Thanks Kerem, sloan and Peter.

I liked what Peter said - catch exception if you can do something useful
with it. So far I found two reasons of when to catch exception:

I guess it depends on what you mean by "catch". In the sense that you'd
want to deal with an exception in that scenario, yes. But the word
"catch" would normally imply the use of an actual "catch" clause in a
try/catch block, and as Jon points out, this sort of cleanup is more
appropriately handled in a "finally" clause instead.

1) If we acquired a critical section and if there is a possibility of
exception, catch block can release that critical section.

In addition to what Jon wrote, note that this is one advantage to using
the C# "lock()" statement where possible: it automatically includes an
implicit try/finally so that locks are released in case of an exception.

2) If we modified a shared resource and if there is exception, we can put
that shared resource in a reusable state (for other application process)
in a
catch block.

It really depends on what your method can do after cleaning up (that is,
restoring this hypothetical shared resource). If the clean-up itself
depends on the exception in some way (even if just that it only should
happen if an exception happens), then yes...that might be an appropriate
place to put the cleanup code. But if the cleanup is something you'd need
to do with or without the exception, then a "finally" clause would be more
appropriate.

Pete

[Ratnesh Maurya]

Yeah that is a functionality missing in .Net, "checked exceptions".

there is a keyword "throws" in Java which warns programmer at compile
time that he has not caught or rethrown an exception which a method
throws whether a sun api or third party.

i personally feel that it is a good feature to have "checked
exceptions", otherwise you need to be depend on documentations, which
are most of the times incomplete. :)

S7 Software

[Jon Skeet [C# MVP]]

Ratnesh Maurya <ra***********@gmail.comwrote:

Yeah that is a functionality missing in .Net, "checked exceptions".

there is a keyword "throws" in Java which warns programmer at compile
time that he has not caught or rethrown an exception which a method
throws whether a sun api or third party.

i personally feel that it is a good feature to have "checked
exceptions", otherwise you need to be depend on documentations, which
are most of the times incomplete. :)

I used to think that way too. For a while I felt like I was driving
without a seatbelt in C#. I've become used to it, and now feel that
Java constrains me unnecessarily. I know it's becoming a cliche to say
so, but I regard checked exceptions as a failed experiment. I think
there's still room for development on this front - something *like*
checked exceptions, but with some streamlining.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[=?Utf-8?B?UmFq?=]

(1)
I was thinking of another statement from Peter's post that Win32 APIs return
error and not exception. If ALL Win32 APIs return error, why are we getting
exceptions in native C/C++ programming. I remember using Microsoft C
exception paradigm like __try()/__exception() blocks. He did mention that
exception handling was evolving in Windows platforms.

(2)
I should have used "finally" instead of "catching exception" in my previous
post.

Thanks,
Raj

"Jon Skeet [C# MVP]" wrote:

Ratnesh Maurya <ra***********@gmail.comwrote:

Yeah that is a functionality missing in .Net, "checked exceptions".

there is a keyword "throws" in Java which warns programmer at compile
time that he has not caught or rethrown an exception which a method
throws whether a sun api or third party.

i personally feel that it is a good feature to have "checked
exceptions", otherwise you need to be depend on documentations, which
are most of the times incomplete. :)

I used to think that way too. For a while I felt like I was driving
without a seatbelt in C#. I've become used to it, and now feel that
Java constrains me unnecessarily. I know it's becoming a cliche to say
so, but I regard checked exceptions as a failed experiment. I think
there's still room for development on this front - something *like*
checked exceptions, but with some streamlining.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com