бросьте новое исключение против отвечающего на письмо сообщения пользователю (избегающий исключения)

Например, если вы пишете Библиотека, которая будет использоваться кодом, о которой вы не знаете или еще не существуют, как эта ошибка обрабатывается, до кода, который делает вызов.

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

Исключения в большинстве случаев, в большинстве окружающих, проще писать тесты для, чем это, написанные на консоль:

it "should reject a negative initial balance" do
  Account.new(-1).should raise_error(ArgumentError, "Invalid balance: -1")
end

Существует две основные причины, по которым я бросает исключения, а не написать сообщение об ошибке на стандартную.

1. Отладка легче - я знаю, если программа вышла из-за ошибки. Кроме того, поскольку исключения в Java могут быть подклассы, я точно знаю, какой тип ошибки произошла.

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

Бр. Исключение:

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

Печатные струны - хорошо - не так.

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

Обычно и языковые агностически говоря, не правильное предположение о том, что исключения являются дорогими. Это зависит от многих факторов.

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

Вопрос генерал и языковой агностик, при этом ответ не подходит к деталям.

Кстати, в зависимости от языка программирования, дизайн обработки ошибок, и количество других факторов, подходы могут быть разными. Тем не менее, это хорошая идея узнать о различных вариантах:

• в C ++, в Boost Project, Руководство по обработке ошибок Сказать:

Не беспокоиться о том, что () сообщение. Приятно иметь сообщение что программатор стоит шансов выяснение, но вы очень маловероятны быть в состоянии составить актуальные и Пользовательно-политическое сообщение об ошибке на Точка исключения брошен (...)

• Krzysztof Cwalina рекомендует набор очень полезных руководящих принципов для .NET, но они на самом деле языковые агностики, такие как , должны ли исключения кода ошибки Информация

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

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

По умолчанию cron выполняет свои задания, используя любую идею sh вашей системы. Это может быть фактическая оболочка Борна или тире , зола , ksh или bash (или другой), связанные с sh (и в результате работающие в режиме POSIX).

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

На x86 команда NOP имеет значение XCHG AX, AX

. 2 Мнемонические команды собираются в один и тот же двоичный операционный код. (На самом деле, я полагаю, ассемблер может использовать любой xchg регистра с собой, но AX или EAX - это то, что обычно используется для nop , насколько мне известно).

xchg ax, ax имеет свойства изменения значений регистра и изменения флагов (эй - это no op!).

Изменить (в ответ на комментарий Анона.):

О, верно - теперь я помню, что есть несколько кодировок для инструкции xchg . Некоторые принимают набор битов mod/r/m (например, многие команды архитектуры Intel x86), которые указывают источник и место назначения. Эти кодировки занимают более одного байта. Существует также специальная кодировка, которая использует один байт и обменивается регистром общего назначения с (E) AX . Если указан регистр (E) AX , то имеется однобайтовая команда NOP. можно также указать, что обмен (E) AX между собой осуществляется с помощью большего варианта инструкции xchg .

Я предполагаю, что MSVC использует многобайтовую версию xchg с (E) AX в качестве источника и назначения, когда он хочет пережечь более одного байта без операции - он занимает то же количество циклов, что и одиночный байт xchg , но использует больше места. При разборке не отображается несколько байтов xchg , декодированных как NOP , даже если результат одинаков.

В частности, xchg eax, eax или nop могут быть закодированы в виде opcodes 0x90 или 0x87 0xc0 в зависимости от того, требуется ли использовать 1 или 2 байт. Разборщик Visual Studio (и, возможно, другие) декодирует код операции 0x90 как команду NOP и декодирует код операции 0x87 0xc0 как xchg eax, eax .

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

Создание исключения:

• дает понять другим программистам, что ситуация исключительна
• позволяет программному обеспечению, вызывающему задействованный метод, четко справиться с проблемой
• показывает инструменты и компилятор, что ситуация исключительна, так что они могут помочь программисту
• позволяет передавать информацию для обработки подпрограмм в самом объекте исключения

Печать последовательностей - ну - на самом деле нет.

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

Это известно как Дизайн по контракту .

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

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