Как бросить хорошие исключения?

Question

Я слышал, что вы никогда не должны бросать строку, потому что не хватает информации, и вы будете ловить исключения, которые вы не ожидаете поймать. Какова хорошая практика для создания исключений? Вы наследуете базовый класс исключений? У вас много исключений или мало? вы делаете MyExceptionClass & или const MyExceptionClass &? и т. д. Также я знаю, что исключения не должны создаваться в деструкторах

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

Answer 1

Как уже было сказано, используйте их только для исключительных ситуаций.

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

public void DoSomethingWithFile() {
    if(!File.Exists(..))
        throw new FileNotFoundException();
}

Предоставьте пользователю другой метод для вызова:

public bool CanDoSomething() {
    return File.Exists(..);
}

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

Также сохраняйте иерархию классов исключений плоской и взгляните на стандартные исключения, такие как InvalidStateException и ArgumentNullExcpetion.

Answer 2

Для текущего проекта мы подумали о подходящем действии, которое может выполнить основной цикл программы. Основная программа принимает XML-сообщения и сохраняет информацию в базе данных (с достаточным количеством обработки между ними). ​​

1. Ошибки данных, указывающие на что-то неправильное на входе. Соответствующее действие - сохранить сообщение в каталоге журнала, но не обработать его.
2. Ошибки инфраструктуры, которые указывают на некоторый подкомпонент (например, очередь ввода, база данных SQL, библиотека JNI), работают неправильно. Выспитесь несколько минут, затем снова подключитесь.
3. Ошибки конфигурации, которые указывают на некоторую конфигурацию аспекта, неработоспособны. Выйти из программы.

Первый элемент - это проверенное исключение, поскольку мы считали проверку данных частью интерфейса метода. Другие не проверяются, так как основной цикл не может знать реализации подкомпонентов, например, реализация может использовать базу данных SQL или просто сохранять данные в памяти - вызывающему не нужно знать.