Бросок Win32Exception
Вы можете добавить пользовательские теги, используя brave.SpanCustomizer. Просто подключите его автоматически, так как компонент уже существует в контексте приложения. Затем вы можете добавить теги следующим образом:
@Autowired
SpanCustomizer spanCustomizer;
...
spanCustomizer.tag("my-tag", "my tag value");
Они превратятся в метки на ваших следах в Stackdriver Trace, по которым вы можете искать .
3 ответа
Это не действительно характерно для исключений Win32; вопрос, когда два различных ошибочных случая должны быть определены двумя различными производными типами Исключения, и когда они должны бросить тот же тип с различными значениями, сохраненными в нем?
К сожалению, на это невозможно ответить, не зная заранее всех ситуаций, Ваш код будет призван.:) Это - проблема только со способностью отфильтровать исключения типом. Вообще говоря, если бы у Вас есть сильное чувство, что было бы полезно рассматривать два ошибочных случая по-другому, бросьте различные типы.
Иначе часто имеет место что строка, возвращенная Исключением. Сообщение просто должно быть зарегистрировано или отображено пользователю.
Если существует дополнительная информация, перенесите Win32Exception с чем-то собственным более высокоуровневым. Например, Вы пытаетесь сделать что-то в файл, и у пользователя, под которым Вы работаете, нет разрешения сделать это. Поймайте Win32Exception, перенесите его в собственный класс исключений, сообщение которого дает имя файла и операцию, предпринимаемую, сопровождаемую сообщением внутреннего исключения.
Мое представление всегда состояло в том, что соответствующий способ обработать это зависит от целевой аудитории и как Ваш класс будет используемым.
Если вызывающая сторона Вашего класса/метода собирается понять, что они звонят в Win32 в одну форму или другого, я использовал бы опцию 1), Вы указали. Это кажется самым "ясным" мне. (Однако, если это верно, я назвал бы Ваш класс способом, который проясняет, что API Win32 будет используемым непосредственно). Однако существуют исключения в BCL, которые на самом деле разделяют Win32Exception на подклассы, чтобы быть более ясными, вместо того, чтобы просто перенести его. Например, SocketException происходит из Win32Exception. Я лично никогда не использовал тот подход, но на потенциально очевидный способ действительно походит обрабатывать это.
Если вызывающая сторона Вашего класса собирается понятия не иметь, что Вы звоните в API Win32 непосредственно, я обработал бы исключение и использовал бы пользовательское, более описательное исключение, которое Вы определяете. Например, если я использую Ваш класс, и нет никакого признака, что Вы используете API Win32 (так как Вы используете его внутренне по некоторой определенной, неочевидной причине), у меня не было бы причины подозревать, что я, возможно, должен обработать Win32Exception. Вы могли всегда документировать это, но кажется более разумным мне захватить его и дать исключение, которое имело бы больше значения в Вашем определенном бизнес-контексте. В этом случае я мог бы перенести начальный Win32Exception как внутреннее исключение (т.е.: Ваш случай 4), но в зависимости от того, что вызвало внутреннюю исключительную ситуацию, я не мог бы.
Кроме того, существуют много раз, когда Win32Exception был бы брошен от собственного вызова, но существуют другие исключения в BCL, которые более релевантны. Дело обстоит так, когда Вы звоните во встроенный API, который не перенесен, но существуют подобные функции, которые перенесены в BCL. В этом случае я, вероятно, захватил бы исключение, удостоверьтесь, что это - то, что я ожидаю, но затем бросаю стандарт, исключение BCL в его месте. Хороший пример этого состоял бы в том, чтобы использовать SecurityException вместо того, чтобы бросить Win32Exception.
В целом, тем не менее, я избежал бы опции 2 и 3, которую Вы перечислили.
Опция два броска общий Тип исключительной ситуации - я в значительной степени рекомендовал бы избежать этого полностью. Кажется неблагоразумным перенести определенное исключение в более обобщенное.
Опция три кажется избыточной - нет действительно никакого преимущества перед Опцией 1.
Лично я сделал бы № 2 или № 4... Предпочтительно № 4. Перенесите Win32Exception в своем исключении, которое контекстно-зависимо. Как это:
void ReadFile()
{
if (!WinApi.NativeFunction(param1, param2, param3))
throw MyReadFileException("Couldn't read file", new Win32Exception());
}
Таким образом, если кто-то ловит исключение, у них будет довольно хорошая идея, где проблема произошла. Я не сделал бы № 1, потому что он требует, чтобы выгода интерпретировала Ваше текстовое сообщение об ошибке. И № 3 действительно не дает дополнительной информации.