Является ли выбрасывание исключения TimeoutException хорошей практикой?

Я определяю класс исключения для класса ввода-вывода устройства.

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

    /// <summary>
    /// The exception that is thrown when the time allotted for talking to the FANUC controller has expired.
    /// </summary>
    [Serializable]
    public class FanucTimeoutException : TimeoutException
    {
        /// <summary>
        /// Initializes a new instance of the <c>FanucLib.FanucTimeoutException</c> class.
        /// </summary>
        public FanucTimeoutException() { }

        /// <summary>
        /// Initializes a new instance of the <c>FanucLib.FanucTimeoutException</c> class with the specified error message.
        /// </summary>
        /// <param name = "message">The message that describes the error. </param>
        public FanucTimeoutException(string message) : base(message)
        {
        }

        /// <summary>
        /// Initializes a new instance of the <c>FanucLib.FanucTimeoutException</c> class with the specified error message and the address trying to access.
        /// </summary>
        /// <param name = "message">The message that describes the error. </param>
        /// <param name = "address">The address trying to access.</param>
        public FanucTimeoutException(string message, string address) : base($"{message} Address: {address}.")
        {
        }

        /// <summary>
        /// Initializes a new instance of the <c>FanucLib.FanucTimeoutException</c> class with
        /// a specified error message and a reference to the inner exception that is the
        /// cause of this exception.
        /// </summary>
        /// <param name = "message">The error message that explains the reason for the exception.</param>
        /// <param name = "innerException">The exception that is the cause of the current exception. If the innerException
        /// parameter is not a null reference, the current exception is raised in a catch block that handles the inner exception.</param>
        public FanucTimeoutException(string message, Exception innerException) : base(message, innerException)
        {
        }

        /// <summary>
        /// Initializes a new instance of the <c>FanucLib.FanucTimeoutException</c> class with
        /// a specified error message, the address trying to access and a reference to the inner exception that is the
        /// cause of this exception.
        /// </summary>
        /// <param name = "message">The error message that explains the reason for the exception.</param>
        /// <param name = "address">The address trying to access.</param>
        /// <param name = "innerException">The exception that is the cause of the current exception. If the innerException
        /// parameter is not a null reference, the current exception is raised in a catch block that handles the inner exception.</param>
        public FanucTimeoutException(string message, string address, Exception innerException) : base($"{message} Address: {address}.", innerException)
        {
        }

        /// <inheritdoc />
        public FanucTimeoutException(SerializationInfo info, StreamingContext context)
        {
        }
    }

Однако я не уверен, что это хорошая практика - бросать TimeoutException. И Руководство по C#, и .Net руководство при проектировании исключений не говорят о TimeoutException. Они предлагают использовать только несколько типов исключений, таких как InvalidOperationException и ArgumentException.

Могу ли я использовать только эти предлагаемые типы исключений или у меня есть свобода использовать весь диапазон, кроме тех, которые не рекомендуются в руководстве?

Вы должны быть в порядке, следуя этим руководствам

Camilo Terevinto 08.09.2018 01:45

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

Timothy Macharia 08.09.2018 01:54

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

TheGeneral 08.09.2018 02:49
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
3
982
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

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

Лично я считаю, что генерировать настраиваемое исключение лучше, чем генерировать стандартное исключение (которое также может быть выброшено через другие области кода), и поэтому не могу точно определить реальную проблему исходного кода.

Кроме того, я считаю, что следует попытаться выбросить исключение вместо того, чтобы возвращать коды ошибок и т.д. (0, 1 и т.д.) для удобства чтения и поддержки. В этом руководстве содержится дополнительная информация о передовых методах:

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions

Другие вопросы по теме