Я определяю класс исключения для класса ввода-вывода устройства.
Я хотел бы вызвать исключение, когда время ожидания связи с устройством истекло. Ниже то, что у меня есть на данный момент:
/// <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
.
Могу ли я использовать только эти предлагаемые типы исключений или у меня есть свобода использовать весь диапазон, кроме тех, которые не рекомендуются в руководстве?
Я действительно думаю, что было бы неплохо выбросить TimeoutException
или, скорее, связать некоторые операции, которые могут вызвать взаимоблокировки, со стандартным периодом ожидания, например 5 секундами. Некоторые операции могут перейти в неактивное состояние, что приведет к остановке MainThread
вашего приложения.
В общем, вы не должны использовать исключения для управления потоком вашего приложения, однако вы используете исключение в исключительных обстоятельствах. в данном случае для устройства ввода-вывода это кажется подходящим. также этот вопрос в первую очередь основан на мнении (немного)
Это должно быть вполне приемлемо. Я не могу представить, почему кто-то не согласен. Есть даже исключения, которые считаются «плохой практикой», но все еще имеют свое применение. Это субъективно, приемлема ли такая практика, но в вашей ситуации я бы сказал, что это нормально. Любой, у кого больше опыта, может не соглашаться.
Лично я считаю, что генерировать настраиваемое исключение лучше, чем генерировать стандартное исключение (которое также может быть выброшено через другие области кода), и поэтому не могу точно определить реальную проблему исходного кода.
Кроме того, я считаю, что следует попытаться выбросить исключение вместо того, чтобы возвращать коды ошибок и т.д. (0, 1 и т.д.) для удобства чтения и поддержки. В этом руководстве содержится дополнительная информация о передовых методах:
https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions
Вы должны быть в порядке, следуя этим руководствам