Author |
Message |
Tim Cools
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
I was reading in some other posts that you only have to catch known exceptions. And that it is not allowed to catch Exception like this:
private void CheckCancelEntryWeighingRecords() { try { mis.Transfer(data.CsvData); //Call to a third party dll } catch (Exception ex) { LogError("Error occured in CheckCancelEntryWeighingRecords", ex); } }
How can I know what exceptions a method can throw So that i can decide on which situation i can recover and on which not I know that the Framework.NET has documented the most exceptions. But what about third party dll's with bad of no documentation I also know i could use reflector to look what the possible exceptions are, but this seems a little bit overkill.
Any sugestions
Thanks in advance, Tim
.NET Development16
|
|
|
|
|
ThE_lOtUs
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
There is no problem catching exception like this.
|
|
|
|
|
nobugz
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
You are supposed to catch specific exceptions in order to recover from them. Those exceptions need to be carefully documented by the software supplier so you have an idea on how to implement the recovery procedure. If no recovery is feasible, there isn't much point for the supplier to document the exception types and there isn't much point to filter the exception type. All you can do is log the error or tell the user. Catching Exception is right thing to do in that case.
|
|
|
|
|
RizwanSharp
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
Yes! it is recommended for good performance of code. You get an exception like ArgumentException (Specific) but you catch Exception (General) it needs unnecessary casting to Base type it may involve multiple layers so the performance of the code is hit.
It is recommended to use multiple catches with a single try and ofcourse to make sure you can use Exception in the last catch statement so make sure application wont be crashed.
About how to know what exception it will through, For MSDN all is shown in tool tip when you choose function after . operator and also in MSDN docs.
For Third party dlls they also provides docs or you can ask them to provide information.
In last as I said you can put a last catch(Exception) so it makes sure if all specific exceptions fail then it saves you ;-)
Cheers!
|
|
|
|
|
ThE_lOtUs
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
Do you have a document I can read that say that it's faster to catch individual exception
|
|
|
|
|
RizwanSharp
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
Book Name: Improving .Net Application Performance and Scalability by Microsoft. Free PDF version available for Download!
Chapter 5, Page Number 231:
Do Not Catch Exceptions That You Cannot Handle
Do not catch exceptions unless you specifically want to record and log the exception
details or can retry a failed operation. Do not arbitrarily catch exceptions unless you
can add some value. You should let the exception propagate up the call stack to a
handler that can perform some appropriate processing.
You should not catch generic exceptions in your code as follows.
catch (Exception e)
{....}
This results in catching all exceptions. Most of these exceptions are rethrown
eventually. Catching generic exceptions in your code makes it harder to debug the
original source of the exception because the contents of the call stack (such as local
variables) are gone.
Explicitly name the exceptions that your code can handle. This allows you to avoid
catching and rethrowing exceptions. The following code catches all System.IO
exceptions.
catch ( System.IO )
{
// evaluate the exception
}
Be Aware That Rethrowing Is Expensive
The cost of using throw to rethrow an existing exception is approximately the same as
throwing a new exception. In the following code, there is no savings from rethrowing
the existing exception.
try {
// do something that may throw an exception...
} catch (Exception e) {
// do something with e
throw;
}
You should consider wrapping exceptions and rethrowing them only when you want
to provide additional diagnostic information.
I Hope it helps!
Cheers ;-)
|
|
|
|
|
nobugz
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
Good advice, no doubt, but only relevant if there is another catch handler on the call stack that can trap the exception that you don't want to handle. That is always true for code that an MSFT programmer writes. But rarely true for code that a customer writes. Necessarily, the very last catch handler, the one that prevents the exception from invoking the unhandled exception crash handler, needs to catch *all* exceptions. Only catching Exception will guarantee this.
The OP appears to be doing the right thing: s/he logs the error, passing both contextual infomation as well as the exception object. I'd assume it records the exception message as well as the call stack trace. Whether that catch handler is in the right location is hard to tell...
|
|
|
|
|
ThE_lOtUs
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
It still does not explain: "You get an exception like ArgumentException (Specific) but you catch Exception (General) it needs unnecessary casting to Base type it may involve multiple layers so the performance of the code is hit."
Unless I'm not understanding it. It say that catching only Exception is slow and I have dought. I'm looking for some document to understand this statment.
Thank
|
|
|
|
|
RizwanSharp
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
I have copy Pasted text from the box which clearly explains why it is slow. This book is not written by me but Microsoft Experts so atleast I'm accepting what is written in that because they made the language and they know what's going on in detail. What we know is only that put our code in try catch but they know what goes behind the scenes when excpetion is thrown and caught. That's why they wrote a book on .Net Application Performance to follow the guildelines to write highly optimize code.
Best Regards,
|
|
|
|
|
nobugz
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
Catching an exception and then rethrowing it is expensive. It is twice as slow as just catching it once.
|
|
|
|
|
Tim Cools
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
My application is a service that looks for records in a db with a specific status and than send it to an external system. I only got the third party dll and no documentation.
Timer()
{
try
{
mis.Open();
CheckDeleted();
CheckOther();
mis.Close();
}
catch (Exception ex)
{
Log("Error in timer", ex);
}
}
One of the arguments that I read was that I also catch the exceptions where the application can not recover from, but I think the application would crash anyway at this point…
Thanks for your thoughts about the matter, but I was looking at some tool that gives me the possible exceptions. I assume that is does not exists. Maybe I write an add-on for reflector myself (when I find some free time someday) that searches automatically for all the exceptions that a method can throw.
Thanks anyway,
Tim
|
|
|
|
|
CommonGenius.com
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
Here's the problem with creating such a tool. Say MethodA takes a reference type parameter, and throws an ArgumentNullException if it is passed a null reference. Your tool will say that MethodA can throw an ArgumentNullException. Now, say MethodB calls MethodA, and passes this. Since it is passing a reference which is known to not be null, it doesn't bother to catch the ArgumentNullException, because it knows it won't be thrown. So your tool would see that MethodB calls MethodA, and doesn't catch the ArgumentNullException, and would report that MethodB can throw an ArgumentNullException, even though it never will.
|
|
|
|
|
Dasa
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
Sounds like checked exception you are looking for, which C# does not have. I'd like it added to C#/.NET - relying on docs is often unreliable (a lot more than using metadata), and MSDN Lib has its share of omissions in this regard. Might be a lot of work updating the library, though, and the associated issue of maintaining compatibility.
|
|
|
|
|
CommonGenius.com
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
There has been a lot of discussion about checked exceptions in C#. You should understand that not including them was not an omission by Microsoft, it was a design decision, and it is not likely to change. Search the MSDN blogs (http://blogs.msdn.com/search/) for "checked exceptions" and you will find lots of interesting discussion by Microsoft employees on the subject.
|
|
|
|
|
Dasa
|
Posted: .NET Base Class Library, How to know what exceptions a method can throw? |
Top |
Yes, and I had read some of the debates dated from C#'s early(ier)
days. I am just remarking as a C# user on the issue since the
thread question illustrates a simple common case for having it, and I
find the arguments for not having it less than convincing.
|
|
|
|
|
|