1

If one has the following code:

data.SaveChanges();

(data is an ObjectContext)

The MSDN doc has listed the OptimisticConcurrencyException as thrown. That's fine but I known that a UpdateException can also be thrown (and possibly others too). How can I know which exceptions a method can throw?

I do not want to catch Exception as I only want to catch exceptions which I know I can handle in some way. This is generally speaking - not just for the example above. There must be some way of knowing which exception a 'built-in' .NET method is throwing.

Nicklas Møller Jepsen
  • 1,248
  • 2
  • 16
  • 34
  • 2
    Some good reading http://stackoverflow.com/a/264755/555547 ;] – Jason Mar 16 '12 at 23:20
  • 1
    The MSDN library lists the exceptions that you *might* want to catch. Another exceptions can be thrown, you *don't* want to catch them because they'll invariably mean something really nasty happened that you can't recover from. Like UpdateException, you can't recover from a corrupt database. – Hans Passant Mar 16 '12 at 23:43
  • Hans: Thank you for the explanation on the MSDN doc - that clarified some things. – Nicklas Møller Jepsen Mar 16 '12 at 23:50

2 Answers2

5

That's not a "native" method; it's an ordinary method that happens to be written by Microsoft rather than you.
Actual native methods cannot throw managed exceptions (although COM interop will convert things to managed exceptions)

Unlike Java, C# does not have exception specifications, so there is no inherent way of knowing what exceptions a method will throw.

Your only options are the documentation or a decompiler.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • You're right, I didn't know what to call it. But I guess it's just an ordinary method. Built-in to the .NET framework. I know that C# doesn't have checked exceptions as for instance Java - I just thought (hoped) that there where some way of knowing whitch exceptions to handle. – Nicklas Møller Jepsen Mar 16 '12 at 23:27
  • Well, the documentation is not reliable and I'm not going to decompile the whole .NET framework. Guess I just have to write bug-free code :) Thanks for the answer, anyway. – Nicklas Møller Jepsen Mar 16 '12 at 23:38
  • @NicklasJepsen Why are you so concerned about trying to handle exceptions? Standard practice is not to handle them and let them float up the call stack. – David Heffernan Mar 17 '12 at 01:20
  • I'm not trying to handle every single exception - I would just like to know which one can actually occur. In the book MCPD Exam Ref 70-518 it's stated that best practice is not just to let the exception float up the stack, but to handle them as close to the code causing it. – Nicklas Møller Jepsen Mar 17 '12 at 08:30
  • @NicklasJepsen: You should handle _relevant_ exceptions (that you can do something about) close to the relevant code. Those exceptions are usually obvious and documented. – SLaks Mar 18 '12 at 05:15
0

Just in case (sorry if it's obvious but there're guys who don't know it) you can hover your mouse over the class name / method call in your editor view in VS. It shows you all the exceptions that can be thrown by the method if defined in documentation.

amdmax
  • 771
  • 3
  • 14