views:

284

answers:

6

I have some code which ignores a specific exception.

try
{
    foreach (FileInfo fi in di.GetFiles())
    {
        collection.Add(fi.Name);
    }
    foreach (DirectoryInfo d in di.GetDirectories())
    {
        populateItems(collection, d);
    }
}
catch (UnauthorizedAccessException ex)
{
   //ignore and move onto next directory
}

of course this results in a compile time warning as ex is unused. Is there some standard accept noop which should be used to remove this warning?

+11  A: 

Just rewrite it as

catch (UnauthorizedAccessException) {}
tvanfosson
I had no idea that was permissible, nifty, thanks.
stimms
But please still include the comment! Just a completely empty block in production code shouldn't pass code review IMO.
Jon Skeet
> "But please still include the comment,,,". Disagree with this. "catch(SomeException) {}" already clearly says "ignore SomeException" and in many cases additional comment will be superfluous.
Joe
+1  A: 

I usually do

Debug.WriteLine(ex.message)

(that way I can just set a breakpoint in the exception, if needed, too)

Booji Boy
+3  A: 

As Dave M. and tvanfosson said, you want to rewrite it as

catch (UnauthorizedAccessException) {}

The bigger question that should be asked, however, is why you are catching an exception on ignoring it (commonly called swallowing the exception)? This is generally a bad idea as it can (and usually does) hide problems in the application at runtime that can lead to very strange results and a difficult time debugging them.

Scott Dorman
At least it's better than "catch(Exception) {}".
MusiGenesis
True, but only marginally better.
Scott Dorman
I think it's sometimes okay to catch an exception and swallow it but there should always be a comment explaining why you're doing it.
Jon Skeet
It is perfectly OK to catch a specific exception like this.
Joe
Agreed. Especially since the code for checking access rights on a directory is nontrivial.
Robert Rossney
In this specific scenario, swallowing the exception is okay, but as Jon mentioned it should be documented somehwere (in a comment) that it's deliberately being eaten. I didn't want this to appear as if it's okay to do this anytime one feels like it.
Scott Dorman
A: 

Even though I'm a Java developer (not C#), @Scott Dorman is absolutely right. Why are you "swallowing the exception"? Better yet, what could throw the UnauthorizedAccessException? Here are common-sense possibilities:

  1. The file doesn't exist
  2. The directory doesn't exist
  3. The current thread of control does not have the correct security privileges. In the *nix world, the current thread may be in the wrong group or the wrong user.
  4. The disk crashed
  5. The file's ACL is set to write only but not read. Likewise, for the directory.

The above of course is an incomplete list.

Alan
Three of those common-sense possibilities won't throw an UnauthorizedAccessException. And the other two are exactly why the method is swallowing the exception: it only wants the files it's authorized to access.
Robert Rossney
A: 

Assuming the comment in your original code is an accurate description of what you're trying to do, I think you want to write it like this:

foreach (FileInfo fi in di.GetFiles())
{
    //TODO:  what exceptions should be handled here?
    collection.Add(fi.Name);
}

// populate collection for each directory we have authorized access to
foreach (DirectoryInfo d in di.GetDirectories())
{
    try
    {
        populateItems(collection, d);
    }
    catch (UnauthorizedAccessException)
    {
        //ignore and move onto next directory
    }
}

And then you need to work on that TODO item.

Robert Rossney
The TODO item is easy - almost certainly you don't want to handle any exceptions there.
Joe
You're probably right. But I'm not going to presume to know what the original poster intended the code to do, and in a code review, I'd make him tell me.
Robert Rossney
A: 

I agree with the people who say it's probably a bad idea to simply ignore the exception. If you're not going to re-throw it then at the very least log it somewhere. I've written small tools that process a list of files where I didn't want errors on individual files to crash the whole program, and in such cases I would print a warning message so I could see which files were skipped.

The only time I personally ever catch an exception without naming it, as in catch(xxxException), is if I'm going to react to it in some way and then re-throw it so that I can catch it in some outer routine. E.g.:

try
{
    // do something
    // ...
}
catch(UnauthorizedAccessException)
{
    // react to this exception in some way
    // ...

    // let _someone_ know the exception happened
    throw;
}
Matthew