6

Do you know if there is any option or extension to generate code required to catch all exceptions thrown by a method in Visual Studio?

For example I'm calling File.WriteAllBytes(...)

That method can throw 9 Exceptions: System.ArgumentException, System.ArgumentNullException, etc, etc.

I want the code for all 9 exceptions:

catch (ArgumentException) {

}
catch (ArgumentNullException) {

}
...

I have seen this behavior in Eclipse for Java but I wonder if there is anything similar in Visual Studio.

BTW I'm using Visual Studio 2012 Premium

John Saunders
  • 160,644
  • 26
  • 247
  • 397
axy108
  • 537
  • 2
  • 4
  • 14
  • 5
    You shouldn't catch ArgumentException or ArgumentNullException, because they are ["boneheaded exceptions"](http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx). You should write your code so that they're never thrown. – Thomas Levesque Oct 10 '13 at 17:33
  • Do you need to handle all of them separately? If not, `catch (Exception)`. – Matt Burland Oct 10 '13 at 17:34
  • Similar: http://stackoverflow.com/questions/2989951/auto-document-exceptions-on-methods-in-c-net – Habib Oct 10 '13 at 17:34
  • Unlike Java, a .NET method need not declare all Exceptions that it might throw. Any method could only rely on the documented exceptions, or perhaps on bytecode analysis. – Eric J. Oct 10 '13 at 17:35
  • @MattBurland Yes I want to handle them separately and provide special feedback to the user depending on the exception that was thrown. – axy108 Oct 10 '13 at 17:37
  • 1
    You must have very sophisticated users that are going to know how to handle an `ArgumentNullException` versus an `ArgumentException`. As Thomas hinted, these should have been caught much earlier and meaningful feedback given. – Matt Burland Oct 10 '13 at 17:40
  • Those two were only an example but what about: PathTooLongException? or DirectoryNotFoundException? or UnauthorizedAccessException? – axy108 Oct 10 '13 at 17:43
  • 3
    I don't think he is worried about whether he should catch all exceptions or not. It appears that he just wants to know if there's a shortcut in VS2012 which generates the `try{} catch{}` blocks automatically, which seems to have been answered [here](http://stackoverflow.com/a/19302504/2777674) – fvdalcin Oct 10 '13 at 17:46
  • @FelipeVogelDalcin You are right I want something to generate code, I am not talking about what exceptions need to be catched or not... – axy108 Oct 10 '13 at 17:48

2 Answers2

14

There is nothing like this in Visual Studio.

The main issue is, unlike Java, C# doesn't support anything like the throws clause. As such, there is no way to directly know what possible exceptions a method will raise. The tooling is built around the language feature, which just doesn't exist in C#.

Anders Hejlsberg discusses this decision in detail in this interview.

That being said, in C#, you typically do not want to explicitly catch all of these exceptions. You should only catch the exceptions which you can handle properly. If you want to catch all exceptions for logging puroses, just use a single catch (Exception e) after any specific exception types, and it will catch all other exceptions.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • Thanks for the answer Reed I read the interview and now I get why I have never seen something similar. I guess I'll need to write manually all the exceptions that I want to handle. – axy108 Oct 10 '13 at 17:54
  • Just to add on to @ReedCopsey's answer if you want to catch them all at the same time using `catch(Exception e)` but do something meaningful with some of those exceptions you can use the `is` operator in an if statement i.e. `if(e is PathTooLongException)` – JNYRanger Oct 10 '13 at 19:09
3

C# is not Java. Not only do you not need to catch all exceptions thrown by a method, it's also a very bad idea.

You should only catch exceptions that you need to handle. If there is nothing in particular that you need to do for a particular exception, then let it bubble up to your caller, which may have something that it needs to do. Or it may not.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • I know C# is not Java but what about if I want to provide different feedback to the user depending on the exception thrown? I know I can catch (Exception ex) and provide a default message no matter what happened or get the ex.Message and show it to the user, but sometimes those messages are not very user friendly. – axy108 Oct 10 '13 at 17:40
  • Your users almost certainly don't need to know at this level of detail. Ask yourself what your user is going to do if you tell him there's an `ArgumentException`! In fact, only the programmer can really do something about that exception. For every exception you report to the user, ask yourself what the user is expected to do about it. – John Saunders Oct 10 '13 at 17:54
  • As I mentioned in a comment previously, those were only a couple of samples, I guess I picked the wrong ones for this question. In my question I'm talking about code generation not what exceptions need to be catched or not. And as I mentioned too what about exceptions like: PathTooLongException? or DirectoryNotFoundException? or UnauthorizedAccessException? The user needs to do something about those exceptions. – axy108 Oct 10 '13 at 18:05
  • The normal message from those exceptions will probably be ok. Microsoft has probably thought about users dealing with `PathTooLongException`. What's wrong with the normal Message property of that exception? – John Saunders Oct 10 '13 at 18:08
  • Nothing wrong with them it is just that sometimes they are not very user friendly and for some of them I like to give some specific feedback to the user on what to do to correct the issue. – axy108 Oct 10 '13 at 18:18
  • @John, of course the logical conclusion to "for every exception you report to the user, ask yourself what the user is expected to do about it" is never report an exception to the user: catch it as early as possible and do something meaningful with it. – David Arno Oct 10 '13 at 18:25
  • Wow @John, I wish there was a downvote comments option. "he normal message from those exceptions will probably be ok. Microsoft has probably thought about users dealing with PathTooLongException. What's wrong with the normal Message property of that exception?" is dreadful advice. Unless they are technically advanced users, there is no way that the the message part of an exception forms anything close to something suitable to report to a user! – David Arno Oct 10 '13 at 18:27
  • @David: when I asked "what's wrong with it", my intention was to receive an answer saying what, specifically, was wrong with specific messages, not to suggest that the default message will always be ok. As I recall, the message from `PathTooLongException` is fairly clear, at least to me. I was interested to know what problem this message causes, more specifically. For instance, do the users not know what a "path" is? That would be an excellent use case for rethrowing a new exception with a better message. – John Saunders Oct 10 '13 at 18:43