Is it ever appropriate for a component to throw a FIleNotFound exception that doesn't at least include the name of the file?

Question

Is it ever appropriate for a component to throw a FileNotFound exception that doesn't at least include the name of the file?

Answer 1

Perhaps, but please don't. The poor guy trying to figure out what's gone wrong and how to fix it, it drives him absolutely wild.

Answer 2

Suppose the file in question should remain invisible -- like it's none of the user's business to know about it. Yes, that's a bit awkward but it's a legitimate circumstance.

(Not that it justifies throwing a FNFException; a generic "Internal Error" would be more appropriate in this case.)

---

A diverse situation is that of the linked question. The COM+ component doesn't really throw a FileNotFoundException. It merely informs the runtime about the occurrence of an error through an inespecific ThrowExceptionForHRInternal() method. Note that it's (potentially) dealing with an unmanaged component, so all available error details are those provided by the OS -- it may have to resort to API calls such as GetLastError().

The OS provides some system error codes which will reveal the nature of the problem. Unfortunately, at this level there's pretty much what all you'll get... so, no file names this time.

Answer 3

I would argue that if you are writing a component, you shouldn't throw an exception like this. This tightly-couples your clients with your implementation. What I mean is, right now, you are reading from a file, and the consumer has been trained to just catch System.IO.IOException. But what about in your next release when the interface stays the same, but you will go to a web service, instead.

An implementation change on your side, just became a BREAKING change for your consumer. They now have to re-write their code to catch a FaultException.

What you should do instead if create your own exceptions (just like they do in the .NET Framework). For this, make on like DataSourceEndpointNotFoundException or something generic like that, and you can attach/include the IOException as an inner exception, to give them more of a clue. But this approach future-proofs your code so that if you change implementation, then your clients won't be affected. Hope that helps.