Я также столкнулся с проблемой нечетного количества элементов (я использую fetch = "join" в моем файле отображения). Я использовал Linq To Nhibernate для решения проблемы, которая используется следующим образом:
var suppliers = (from supplier in session.Linq<Supplier>()
from product in supplier.Products
where product.Category.Name == produtCategoryName
select supplier).ToList().Distinct();
Я бы сказал, что все зависит от опыта. Я по-прежнему часто обнаруживаю новые исключения, и уже некоторое время я работаю со многими аспектами .NET! Что бы вы хотели, чтобы этот источник вам рассказал? Выбор подходящего типа исключения может показаться очень зависимым от контекста, поэтому я сомневаюсь в том, какой уровень рекомендаций он может предложить. Перечисление наиболее распространенных - это самое лучшее, что он может предоставить. Имена и описания типов исключений в Intellisense обычно с хорошей ясностью объясняют их сценарии использования.
Я рекомендую просто ознакомиться со всеми основными (в частности, в System
, ) System.IO
и любые другие пространства имен, которые вы часто используете), и изучите другие по ходу дела. Я считаю, что обычно избегаю использования небольшого числа. Если вы случайно используете более общий тип исключения, когда в BCL уже существует более конкретный тип исключения, то это не является большим преступлением, и его можно легко изменить позже. Честно говоря, для любой конкретной ошибки вам часто нужно будет создать свой собственный класс, наследующий от Exception
.
Надеюсь, что это поможет.
Изменить: Если вы хотите краткое руководство по наиболее распространенным из них см. на странице Общие классы исключений в MSDN.
Общие типы исключений и их объяснения
Я думаю, что это, вероятно, поможет вам выяснить, какие исключения наиболее подходят для использования. Вы также можете изучить документацию MSDN для получения дополнительной информации о классе Exception и всех его типах, если вам нужно.
У Кшиштофа Квалины есть хороший пост по этому поводу см. Главу «1.1.1 Выбор правильного типа исключения для создания»
PS Рассмотрите возможность подписки на его блог. Хорошее чтение!
Чтобы ответить на ваш вопрос: InvalidEnumArgumentException
, потому что генерирует наиболее конкретное (наиболее производное) исключение, которое имеет смысл.
И вызывающие объекты, которые перехватывают исключение ArgumentException, также перехватывают исключение InvalidEnumArgumentException ...
Если вы посмотрите статью MSDN о System.Exception , справа внизу страницы находится целый список типов исключений BCL. которые наследуют Exception. Это не совсем исчерпывающий список того, что следует использовать для чего, но он дает вам отличное место для начала проверки типов исключений. Пройдя через каждый из них, вы узнаете, для чего их следует использовать:
Также есть довольно подробная статья о. Иерархию исключений .NET можно найти по адресу:
Фактически весь раздел библиотеки MSDN об обработке и выдаче исключений довольно хорошо:
Я думаю, что реальный вопрос состоит в том, чтобы спросить себя: «Какой тип исключения я хочу справиться? " Если у вас не будет специальной обработки для InvalidEnumArgumentException или ArgumentException, тогда они не будут иметь преимуществ перед обычным старым исключением.
Я обычно либо выбрасываю исключение, либо заключаю исключение в настраиваемое исключение.
Отредактировано в Добавить: В какой-то момент я напомню, что руководство Microsoft заключалось в том, что ваше приложение никогда не должно генерировать исключения фреймворка, а должно генерировать только расширения ApplicationException.
У меня есть большинство распространенных исключений, написанных на открытках на моем столе, и я использую их, когда люди пытаются взаимодействовать со мной исключительным образом.
Это действительно хорошая практика для работы выбери какое исключение подходит лучше всего ...
Я чаще всего использую OperationNotSupportedException
Я обычно определяю свою собственную структуру исключений, сначала создавая базовое исключение:
class MyProjectNameException:Exception
{
...constructors, etc
}
, а затем производные классы для более точных исключений. Таким образом, вы точно знаете, когда ожидать, какое исключение, и вы знаете, было ли исключение создано вами или фреймворком.
Если вы найдете исключение, которое подходит, вы можете использовать его.
Если есть сомнения, просто используйте ApplicationException
. Это исключение, предназначенное для кода, который не является частью стандартной библиотеки.
Если исключение не предназначено для использования стандартизированным способом (например, перехват базового класса IOException
для перехвата любого I / O, связанная с ошибкой), сообщение, которое вы добавляете в исключение, более полезно, чем тип исключения.