when to handle exception

[Raj]

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

 

[Kerem Gümrükcü]

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

--

 

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

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

 

[Jon Skeet [C# MVP]]

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.

 

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

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.

 

[Raj]

(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