Throw FileLoadException or just IOException

Question

I am writing an app and I want to load a file based on a path provided by the user. I check the extension of the file and when the extension does not match anything I recognize I want to throw an exception.

I could throw an IOException. But, I figured there could be a more detailed exception derived from that. So I looked at MSDN and found FileLoadException. The name suggests that my error would fit in this category, but.... when I look on MSDN it says: "Represents the error that occurs when a Assembly file is found but cannot be loaded." and "The exception that is thrown when a managed assembly is found but cannot be loaded." That is absolutely not what is the case with my error.

So what is the question then? Well, I wonder if the documentation actually means that the exception is meant to be thrown for this purpose only or that they just mean that they throw that exception in that specific case, but do not really specify when others should throw it.

On the IOException page on MSDN it does advice to use FileLoadException where appropriate:

IOException is the base class for exceptions thrown while accessing information using streams, files and directories.

The Base Class Library includes the following types, each of which is a derived class of IOException:

• DirectoryNotFoundException
• EndOfStreamException
• FileNotFoundException
• FileLoadException
• PathTooLongException

Where appropriate, use these types instead of IOException.

Summarized: In case of an unknown file extension, should I throw an IOException or a FileLoadException (I do not want to define my own exception).

Thanks in advance.

Answer 1

I wouldn't throw an exception that is documented to be of a very specific use-case and might confuse others.

If you can't define a new exception, stick with IOException.

Answer 2

It seems a case of just validating the user data.

Why would you want to throw an exception and just not inform the user that he provided an extension that is not recognized by your application?

If you're using the OpenFileDialog you can even use the OpenFileDialog.Filter in order to allow the user to only select a file with an extension supported by your application.

Answer 3

FileLoadException wouldn't seem to be a good fit, because it's specifically for assemblies.

IOException is suitable, but it feels very generic and wont let callers handle it gracefully, distinguishing it from more general errors.

If you really have to throw an exception here, consider NotSupportedException, which identifies an attempt to perform an operation which your object does not support, in this case loading a file format you don't recognise.

Answer 4

You should throw IOException, and never throw FileLoadException which is very specific and "technical" (whereas your exception should be "application oriented"). Try to analyze FileLoadException type with Reflector (in mscorlib), you'll see that it's only used for the purpose defined in the msdn. Then imagine one day your code used in a "plugin context", how will react the host program catching a FileLoadException meaning an assembly failed to load properly ...

Answer 5

Good practice is to define your own exceptions: derive one from whether Exception or any other more specific Exception subclass.

This will save your time during testing as well as provide you more information with future feedback: you can differ between some exceptions that are not handled in you code and those your own business logic throws based on your specific rules.

Speaking of this case, I advise you create FileExtensionException derived from IOException. This will pretty much ease you code: you won't have to check error message providing separate catch block for new exception type.