Класс пользовательских исключений

Question

У меня есть абстрактный класс Camera.Есть некоторые производные классы, которые будут обрабатывать определенные типы камер.Каждый тип камеры имеет свои исключения, в то время как некоторые из них вообще не имеют исключений, они возвращают перечисление с типом ошибки.

Я хочу знать, согласны ли вы, люди, с этой реализацией:

Все определенные классы будут обрабатывать свои исключения (или тип ошибки enum) и преобразуют его в общее исключение (например, CameraException: Exception) и выдают его.

Это хорошая / рекомендуемая реализация?

Answer 1

Вы хотели бы объединить понятия ошибок в общую иерархию классов CameraException.Если цель состоит в том, чтобы абстрагировать реализацию камеры, следует также абстрагировать ошибки и в эту общую среду исключений.

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

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

Например, если вы попытаетесь выполнить операцию с памятью камеры, карта памяти не вставлена, ни одна из них не будет вставлена, выведите NoMemoryCardInCameraException, который может наследоваться от CameraException.

Если вы действительно хотите, чтобы эти данные поставщика были доступны, вы можете иметь свойство в CameraException с именем Detail или что-то, что будет абстрактным классом или Dictionary пар ключ-значение сдетали реализации.Таким образом, если кто-то действительно хочет покопаться в фактических кодах ошибок, перечислениях и т. Д. От поставщика, которого он может.

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

Надеюсь, что это немного прояснит ...

Answer 2

Прикладные уровни должны определять пользовательские типы исключений, независимо от того, что говорит Microsoft.Предположим, у кого-то есть абстрактный класс WrappedCamera, производные которого служат обертками для таких классов, как CanonCamera, NikonCamera, KodakCamera, и будущие производные которых будут служить обертками для классов, разработанных в будущем.Предположим, что класс WrappedWaldorfCamera оборачивает WaldorfCamera, а когда он вызывает WaldorfCamera.GetPictureCount (), этот метод вызывает исключение WaldorfCamera.WrongCameraModeException.Если WrappedWaldorfCamera разрешает возникновение исключения, что будет с ним делать приложение?Если приложение не предполагает, что все неизвестные типы исключений должны отображать сообщение, но позволяют программе продолжаться, приложение не может знать, что исключение WaldorfCamera.WrongCameraModeException было безопасно перехватить.Напротив, если бы WrappedWaldorfCamera генерировал исключение WrappedCamera.CameraModeException, которое получено из WrappedCamera.CleanNonConnectStateException, приложение знало бы, что оно должно перехватить исключение и обработать его.

Кстати, чтобы никто не жаловался, что вся «проблема»был создан WaldorfCamera, определяющим его собственное исключение, рассмотрите ситуацию, если вместо этого WrappedWaldorfCamera разрешит перенаправлять InvalidOperationException.Что приложение должно делать с одним из них?

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

Answer 3

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

Если абоненты разных типов камер не сделают ничего, кроме этого:

try
{
    // Do something with some kind of camera
}
catch (CameraException ex)
{
    // Handle the fact that there was a camera problem
}

Тогда нет необходимости в пользовательских производных типах CameraException. Никого не волнует, какой конкретный производный тип был брошен.

На самом деле, если ваши абоненты не будут делать ничего другого, когда выбрасывается CameraException против любого другого вида исключения, тогда нет необходимости в CameraException. Просто используйте что-то вроде InvalidOperationException и добавьте информативное свойство Message:

throw new InvalidOperationException(
    String.Format("Invalid attempt to set the f-stop to {0} while in video mode",
                  this.FStop));

Answer 4

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