Как исключения должны быть запланированы на архитектурном уровне?
Вот что мы придумали для копирования одного поля в другое для ~ 150_000 записей. Это заняло около 6 минут, но все еще значительно менее ресурсоемким, чем это было бы для создания экземпляра и повторения одного и того же количества объектов ruby.
js_query = %({
$or : [
{
'settings.mobile_notifications' : { $exists : false },
'settings.mobile_admin_notifications' : { $exists : false }
}
]
})
js_for_each = %(function(user) {
if (!user.settings.hasOwnProperty('mobile_notifications')) {
user.settings.mobile_notifications = user.settings.email_notifications;
}
if (!user.settings.hasOwnProperty('mobile_admin_notifications')) {
user.settings.mobile_admin_notifications = user.settings.email_admin_notifications;
}
db.users.save(user);
})
js = "db.users.find(#{js_query}).forEach(#{js_for_each});"
Mongoid::Sessions.default.command('$eval' => js)
4 ответа
"Эффективный Java", 2-й. редактор Bloch, имеет некоторый хороший совет в главе 9.
"Жесткий Java", Simmons, имеет некоторый хороший совет в главе 5.
Я также бесстыдно упомяну, что записал мелкий инструмент для управления исходным кодом исключения Java. Код исключения часто очень избыточен, все, о чем Вы обычно заботитесь, тип. Мой инструмент принимает конфигурационный файл, который называет типы исключительной ситуации, затем генерирует код для тех исключений.
Я пытаюсь удостовериться, что количество использования мест попытки/наконец значительно превосходит численностью количество мест с помощью попытки/выгоды. выгода будет обычно резервироваться для ловли исключений на верхнем уровне - где они могут разумно быть обработаны, или контакт за исключениями из API платформы.
В этом случае пока Вы даете исключениям значимые сообщения и цепочечные исключения в случае необходимости, не будучи способен определять, что исключением его классом не является большая потеря. Я часто бросаю RuntimeException, а не пытаюсь разработать класс исключений для каждого мыслимого ошибочного случая - но Ваше мнение об этом будет зависеть от того, где Вы сидите на проверенном по сравнению с дебатами исключения непроверенными.
Я половина соглашаюсь с комментарием Apocalisp. Экземпляры Исключения должны быть зарезервированы для случаев, где ошибка данных или обработки произошла, но может быть восстановлена с Пользовательским или Системным вмешательством. Экземпляры RuntimeException должны быть зарезервированы для тех случаев, когда никакое вмешательство в рамках ограничений Вашего приложения не может решить вопрос. Эти два типа таким образом известны как Проверенные и исключения Непроверенные.
Пример исключений Непроверенных был бы то, если физический ресурс (такой как база данных или шина сообщения) недоступен. RuntimeException хорош в этом случае, потому что Вы не планируете ресурс быть недоступными, таким образом, Ваша бизнес-логика не должна постоянно проверять на DatabaseUnavailableException или что-то подобное. Можно обработать RuntimeExceptions по-другому (возможно, AOP, посылающий электронное письмо), чтобы сообщить, что отключение электричества и позволять штату или поддержке устраняет физическую проблему.
Примерами Контролируемых исключительных ситуаций был бы плохой ввод данных, или доступ неполных данных или что-то, что на самом деле приводит бизнес-логику к сбою, но может быть проверено и восстановлено с. Пример этого мог бы быть то, что Пользователь, которого Вы искали, недоступен. Это - отдельное условие в Вашей бизнес-логике, которая может быть проверена и обработана (скажите частью Представления Вашего приложения, которое затем сообщает о сообщении Исключения как о сообщении об ошибке Пользователю).
Много платформ используют эту модель, и это, кажется, работает лучше, чем я видел иначе.
Однако многие действительно заменяют контролируемые исключительные ситуации возвращенными пустыми указателями,-1, пустой строкой или Числом. MIN_VALUE. В то время как это хорошо, если Вы обычно не ожидаете эти значения от источника данных или метода, он должен, вероятно, представленный как исключение.
Я обычно нахожу, что завладение по контролируемым исключительным ситуациям является излишеством. Исключения должны быть зарезервированы для неожиданных состояний ошибки, с которых не может обоснованно восстановиться программа. Для них я склонен соглашаться с тем, что Вы наблюдали, что специальные ошибочные типы имеют тенденцию терять свое значение.
Как правило выдайте исключение, когда все следующее будет верно:
- Условие не может быть восстановлено отсюда.
- Вызывающая сторона, как могут обоснованно ожидать, не восстановится с этого условия.
- Кто-то захочет отладить ситуацию, таким образом, они могли бы хотеть видеть отслеживание стека.
Вы найдете, что, если все те верны, тип исключения не важен, и можно также бросить java.lang. Ошибка. Если какой-либо из них является ложью, то исключением является, вероятно, излишество (Вам действительно нужны тип, сообщение и отслеживание стека?)
Вместо этого полагайте, что увеличение типа возврата методов указывает на ожидаемые виды отказа. Например, используйте тип Опции <A> для методов, где может иметь смысл не возвращать значение в некоторых случаях. Используйте Любой <A, B> тип для методов, где Вы, возможно, должны были бы возвратить значение, тип которого зависит от отказа или успеха. Где у Вас, возможно, были специализированные подтипы Исключения прежде, можно вместо этого просто использовать Любого <Сбой, A>, где Сбой является просто перечислением по видам отказов, которые ожидаются.