Почему в .Net нет исключения System.ClassNotFoundException?

Question

При попытке найти тип (обычно класс) во время выполнения, если имя передано

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

Перегрузка не может быть обнаружена, исключение - TypeLoadException.

Я понимаю, что за этим стоит мысль о том, что CLR считает, что проблема в том, что мы (еще) не загрузили (или любую) сборку, которая содержит искомый тип, но, как я думаю, проблема заключается в том, что проблема является то, что CLR не может найти класс по его имени. (Конечно, название могло быть написано неправильно.)

Похоже, у меня есть два варианта, если я хочу сообщить клиентам моего ориентированного на рефлексию инструмента define-code-at-runtime, что запрошенный ими класс не найден - либо сообщить им с помощью TypeLoadException, либо определить мое собственное исключение ClassNotFoundException.

Я нашел эту ссылку , которая дает (по-видимому, хорошую и, безусловно, полную) информацию о создании пользовательских классов исключений (в C #), но это довольно много работы для (правильной реализации) такой простой идеи.

Похоже, что я также хочу создать что-то, что знает имена сборок общих классов (или их пространства имен), которые, я думаю, мои клиенты, возможно, захотят использовать, чтобы я мог загрузить соответствующую сборку, если / когда мой пользователь просит класс, который находится в довольно известной, но еще не загруженной сборке. Это также, кажется, feechur, который BCL вполне мог бы обеспечить для нас. (Полагаю, для этого и нужно событие AppDomain.TypeResolve, но я собираюсь задать отдельный вопрос, чтобы попытаться найти легкодоступную и расширяемую реализацию этой концепции.)

А пока я спрошу еще раз - почему ClassNotFoundException еще не определено?

Answer 1

Если ваше пользовательское исключение TypeNotFoundException предоставляет больше информации, чем доступно в CLR TypeLoadException, то я думаю, что вполне приемлемо создать новый тип исключения.

Одна вещь, которую стоит рассмотреть, - может ли вам понадобиться работать с существующим кодом, который уже пытается перехватить исключительную ситуацию TypeLoadException в CLR. Если это так, то этот код может больше не работать, поскольку ваше исключение не будет перехвачено этим кодом.

Я могу только догадываться, почему исключение CLR объясняется тем, что я не писал этот код. Исключение не обязательно может точно определить, почему тип не может быть найден. Как вы заметили, одна из возможностей заключается в том, что имя типа было написано с ошибкой. Другими причинами могут быть сбой требований безопасности, файл сборки не может быть прочитан с диска, найдена неправильная версия сборки, открытый ключ не совпадает, сборка не найдена, пути распознавания типа в AppDomain не выполнены, или любое количество других причин.

Из-за множества возможных причин сбоя исключение является довольно общим, поскольку в противном случае было бы 20 типов исключений, которые, я думаю, большинство согласится, слишком велики.

Еще одна вещь, о которой следует думать с исключениями, это: предположим, что кто-то встречает исключение - что вы ожидаете от него тогда? То есть каким значимым образом вы ожидаете, что исключение будет обработано программно. Если исключение предназначено только для разработчика, то все, что действительно имеет значение, это сообщение об исключении, а не его тип. Если исключение обрабатывается программно, то как бы вы обработали эти 20 случаев по-другому? Или они вообще будут другими?

Answer 2

Type.GetType() не только имеет дело с классами. Вы можете получить тип структур, перечислений и т. Д. Это означало бы, что любое исключение с именем ClassNotFoundException будет иметь неправильное имя, если вы пытаетесь загрузить структуру, и назвало ее неправильно.

Таким образом, родовое имя TypeLoadException.