Почему Исключения на этапе выполнения “неконтролируемы” в Java?
Я делаю то же - я называю их всех модульными тестами, но в какой-то момент у меня есть "модульный тест", который покрывает так много, я часто переименовываю его к ".. IntegrationTest" - просто смена имени только, ничто иное не изменяется.
я думаю, что существует продолжение от "атомарных тестов" (тестирование одного крошечного класса или метода) к модульным тестам (уровень класса) и интеграционные тесты - и затем функциональное испытание (которые обычно покрывают намного больше материала от вершины вниз) - кажется, нет определенного прочь.
, Если Ваши наборы тестов данные, и возможно загружает базу данных/файл и т.д., то, возможно, ее больше интеграционного теста (интеграционные тесты я нахожу использование меньшим количеством насмешек и более реальных классов, но это не означает, Вы не можете дразнить часть системы).
3 ответа
Если бы вы этого не сделали, вам пришлось бы иметь блоки try / catch каждый раз, когда вы обращались к элементу массива, выполняли операцию деления и многие другие распространенные сценарии.
Другими словами. представьте себе этот код:
Map map = ...
int i = ...
(int[])map.get("foo")[3] = 2334 / i;
должен будет проверить наличие ClassCastException , ArrayIndexOutofBoundsException , ArithmeticException , UnsupportedOperationException [111715150] и [111715150] UnsupportedOperationException [111715150] 1117152]
В Java проблема не в неотмеченных исключениях. Проверенные исключения - очень спорная тема. Некоторые говорят, что это был в основном эксперимент с Java, и на практике они не работают, но вы найдете множество людей, которые утверждают, что они хороши.
Никто не утверждает, что непроверенные исключения - это плохо.
Это просто означает, что компилятор не заставит вас искать исключение, но вы все равно можете выбросить его во время выполнения. В качестве одного из преимуществ это позволяет вам генерировать новые исключения из ваших классов, не требуя от вас изменения вашего интерфейса, что заставляет вызывающих абонентов изменять свой код.
The idea of the two kinds of exceptions in Java (checked and unchecked) is that checked exceptions should be used for error conditions that can reasonably be expected to happen, and unchecked exceptions should be used for unexpected error conditions.
For example if a file isn't found, you get a FileNotFoundException, and it's reasonable to expect your program to be able to handle such a condition. Unchecked exceptions should be used only for problems that shouldn't happen, and that really mean that there is a bug in the program if such a problem happens. For example, a NullPointerException means that your program is trying to dereference a variable that is null and that's most likely a bug.
The Java compiler forces the programmer to handle checked exceptions. This makes the programming language safer - it means that the programmer is forced to think about error conditions, which should make the program more robust.
The compiler doesn't check unchecked exceptions, because unchecked exceptions aren't supposed to happen anyway and if they do, there's nothing that the program could reasonably do at runtime; the programmer must solve the bug.
There has been some criticism to this feature in Java, some people even call checked exceptions a failed experiment and some people propose to remove checked exceptions from Java.