Question

so in my program I have parts where I use try catch blocks like this

try
{
  DirectoryInfo dirInfo = new DirectoryInfo(someString); 
 //I don't know if that directory exists
 //I don't know if that string is valid path string... it could be anything

 //Some operations here
}
catch(Exception iDontCareWhyItFailed)
{
  //Didn't work? great... we will say: somethings wrong, try again/next one
}

Of course I probably could do checks to see if the string is valid path (regex), then I would check if directory exists, then I could catch various exceptions to see why my routine failed and give more info… But in my program it’s not really necessary. Now I just really need to know if this is acceptable, and what would a pro say/think about that. Thanks a lot for attention.

Answer 1

If you truly don’t care why it failed, and your program can’t reasonably do anything to recover, then it’s OK to do something like this; I’d rather maintain something like this than code that uses 3 try/catch blocks to do the same thing but without adding any additional value. I do like the name of the exception that communicates it isn’t of importance, that’s better than catching a variable named ex.

Some suggestions, however:

1. If you’re going to “catch and ignore”, be more explicit about which Exception types are OK to ignore. If you know you can ignore FileNotFoundException, or any class of IOException, then just catch that.

2. If you’re going to catch a generic Exception, consider logging the exception somewhere. Your current approach could be a maintenance nightmare if a logical defect exists in your try block. For instance, say you code an off-by-one error with regards to an array index… your current code will swallow that and provide no indication that something more important than “directory does not exist” occurred.