Why is there no System.ClassNotFoundException in .Net?

Question

When trying to locate a Type (typically a class) at runtime, if the name passed to the

  Type.GetType(string typeName, bool throwOnError = True)

overload cannot be located, the exception raised is TypeLoadException.

I understand that the thinking behind this is that the CLR believes that the problem is that we have not (yet) loaded the (or any) Assembly that contains the Type sought, but the way I think of it is that the problem is that the CLR cannot find the class given its name. (The name may have been mis-spelled, of course.)

It seems that I have two choices if I want to tell the clients of my Reflection-oriented define-code-at-runtime tool that the class they asked for wasn't found -- either tell them with TypeLoadException, or define my own ClassNotFoundException.

I found this link that gives (apparently good and certainly complete) information on creating custom Exception classes (in C#), but that's quite a lot of work for (properly implementing) such a simple idea.

It appears that I'll also want to build something that knows the Assembly names of common classes (or their namespaces) that I think my clients might want to use, so that I can load the proper Assembly if/when my user asks for a class that's in a somewhat-well-known but not-yet-loaded Assembly. This also seems to be a feechur that the BCL might well have provided for us. (I suppose that's what the AppDomain.TypeResolve event is for, but I'm going to ask a separate question to try to locate an easily-reusable and -extendable implementation of that concept.)

Meanwhile, I'll ask again -- why isn't ClassNotFoundException already defined?

Answer 1

Type.GetType() doesn't just deal with classes. You can get the type of structs, enums, etc. That would mean any exception called ClassNotFoundException would be incorrectly named if you were attempting to load a struct, and named it incorrectly.

Thus the generic name, TypeLoadException.

Answer 2

If your custom TypeNotFoundException provides more information than is available from the CLR's TypeLoadException then I think it's perfectly acceptable to create the new exception type.

One thing to consider is whether you might need to operate with existing code that already tries to catch the CLR's TypeLoadException. If so then that code might no longer work because your exception won't be caught by that code.

I can only guess at why the CLR's exception is why it is because I didn't write that code. The exception is not necessarily able to detect precisely why a type could not be found. As you noted, one possibility is that the type name was misspelled. Other reasons might be security demands have failed, the assembly file could not be read from disk, the wrong assembly version was found, the public key didn't match, the assembly was not in the probing paths, the AppDomain's type resolver failed, or any number of other reasons.

Because of the numerous possible causes for failure the exception is quite generic because otherwise there would be 20 exception types, which I think most would agree is too many.

Another thing to think of with exceptions is this: Suppose someone encounters the exception - what do you expect them to then do? That is, in what meaningful way do you expect the exception to be programmatically handled. If the exception is only meant for a developer then all that really matters is the exception message and not the exception's type. If the exception is programmatically handled then how would you handle these 20 cases differently? Or would they even be different?