Защитное программирование и обработка исключений

Question

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

(б) Кратко опишите в общих чертах, что подразумевается под обработкой исключений в Java и чем это отличается от защитного программирования. [5 баллов]

Я всегда думал, что защитное программирование - это целая парадигма программирования, и что обработка исключений является его частью. Во время экзамена я пишу, что в «защитном программировании» программист пытается выяснить все возможные проблемы, прежде чем выполнять логический код, а затем вернуть значение ошибки (пример 0) из этой функции, тогда как при обработке исключений возникают потенциальные ошибки, которые обнаруживаются с помощью специального механизма, в котором эти ошибки непосредственно интерпретируются. Это правильно? Какие должны быть правильные ответы?

Answer 1

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

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

И никогда не забывайте, что ваши пользователи не только ваши клиенты.Если вы отвечаете за API библиотеки, вашими пользователями могут быть другие отделы.В этом случае одной из самых ярких жалоб, которые я когда-либо слышал в своей жизни, было:

Даже после того, как мы удалили все неудачные юнит-тесты, программа не работала

Answer 2

Защитное программирование, для меня, означает написание кода для обработки случаев, которые, как вы думаете, не произойдут или даже могут произойти, потому что вы уверены, что ваши собственные убеждения ненадежны.

Например (не скомпилировано или протестировано, применяются условия):

private String findSmallestString(Collection<String> strings) {
    if (strings == null || strings.isEmpty()) return null;
    Iterator<String> stringsIt = strings.iterator();
    try {
        String smallestString = stringsIt.next();
        while (stringsIt.hasNext()) {
            String candidateString = stringsIt.next();
            if (candidateString == null) continue;
            if (candidateString.compareTo(smallestString) < 0) {
                smallestString = candidateString;
            }
        }
        return smallestString;
    }
    catch (NoSuchElementException e) {
        return null;
    }
}

Там, возможно, защитные функции включают в себя:

• Пустое или охранное предложение вверху; это закрытый метод, поэтому вы должны быть уверены, что он никогда не будет вызываться с пустой или пустой коллекцией
• Try-catch для NoSuchElementException; вы можете доказать, что содержащийся в нем код никогда не вызовет это исключение, если итератор выполнит свой контракт.
• Предложение защиты от недействительности для строк (кроме первой!), Выходящих из итератора; опять же, поскольку это закрытый метод, вы, вероятно, должны быть в состоянии убедиться, что параметр коллекции не содержит нулей (и что бы вы делали, добавляя пустые значения в коллекции в любом случае?)

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

Для меня кислотный тест защитного программирования состоит в том, что вы не думаете, что защита когда-либо будет использоваться.