C# explicitly defining what exceptions are thrown

In Java, you explicitly define what exceptions are thrown using the "throws" keyword. That way, anyone calling your method knows what to catch.

Is there something in C#? If not, how do I know what exceptions to catch, or how do I let others know what exceptions to catch?

Also, if I am defining an interface, is there a way to 开发者_如何学Gosay "methodX() should throw this exception on error"?

There is nothing equivalent in C#: The Trouble with Checked Exceptions

Other than documentation, there is no way to declare an interface to say "methodX() should throw this exception on error".

C#/.net does not have checked Exceptions, they proved to be less useful in large scale systems than first thought. In a lot of projects the time to maintain the check exception specs was a lot greater than the debugging time saved by having them.

Checked Exceptions seem like a good ideal until you have methods that can take delegates or calls into object you pass in. Take a simple case, the Sort() method on a list can’t know what exceptions it will throw, as it does not know what exceptions the Compar() method on the objects being sorted will throw.

So the spec for the exceptions a method may throw must be able to include information on how exceptions are populated from pass in objects and delegates. No one knows how to do this!

However there are tools that you check if you are catching all exceptions – see Exception Hunter by Red Gate. I personally don’t see much value in these tool, however if you like checked exceptions you may find them useful. ==> Looks like Exception Hunter wasn't too useful, so Redgate discontinued Exception Hunter a long while ago:

This feature is not available in C#. You can make proper XML documentation (3 slashes ///) and state what exceptions are being thrown.

This will be picked up by the IntelliSense mechanism and will be visible for the users of the class/method before they use it.

C# does not support this. (Not that I know anyway). What you can do is use Xml Comments so that while calling you methods this data will be shown by intellisense.

As far as I'm aware there is no throws declaration in C# you can document your method indicating that it throws an exception but no forced error handling.

C# doesn't support checked exceptions. The language designers consider checked exceptions in the way java uses them a bad idea.

Some workarounds

Let me cite this medium article: It's almost 2020 and yet... Checked exceptions are still a thing

Among the many reasons why it's a bad idea, putting the checked exceptions in the contract (interfaces):

1. makes it impossible to change the implementation of an interface with a different one which throws different exceptions
2. exposes implementation details
3. a change of the checked exceptions of an API interface, makes it necessary to change the whole chain of interfaces in the call stack

For example, imagine that you are implementing a repository based on SQL Server, so you expose all kind of SQL Server specific exceptions. Then you want to move it to MySQL or Cosmos BD. Of course:

1. the implementation can't be changed to a new one that need to throw different exceptions. Also related to this, if you have different implementations of the storage, you can't just change them by configuration, but you need to have different compilations of the code for each storage backend
2. this is the explanation for 1: as the interface showed the implementation details (SQL Server exceptions) know you can't just change it
3. if you need to make the change, prepare to change the interface at all levels, since the API that uses the database up to the lates consumer in the call stack chain.

The articles cited above includes pointers to many explanations to discourage the use of checked exceptions, included this by the creator of C#: The trouble with checked exceptions