Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант
0/0

Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант

Уважаемые читатели!
Тут можно читать бесплатно Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант. Жанр: Программирование. Так же Вы можете читать полную версию (весь текст) онлайн книги без регистрации и SMS на сайте Knigi-online.info (книги онлайн) или прочесть краткое содержание, описание, предисловие (аннотацию) от автора и ознакомиться с отзывами (комментариями) о произведении.
Описание онлайн-книги Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант:
Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.
Читем онлайн Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 30 31 32 33 34 35 36 37 38 ... 74

}

Эта проблема являются разновидностью так называемого «Heisen-bug» – процесса отладки, изменяющего поведение отлаживаемой системы (см. [URL 52]).

Другие разделы, относящиеся к данной теме:

• Отладка

• Проектирование по контракту

• Балансировка ресурсов

• Программирование в расчете на совпадение

Упражнения

19. Быстрый тест на ощущение реальности. Какие из перечисленных «невозможных» событий могут случаться в реальности? (Ответ см. в Приложении В.)

1. Месяц, количество дней в котором меньше 28

2. Stat(".",&sb)== –1 (т. е. невозможно обращение к текущему каталогу)

3. В языке С++: а = 2; b = 3; if (а + b != 5) exit(1);

4. Треугольник, сумма величин внутренних углов которого не равна 180°

5. Минута, состоящая не из 60 секунд

6. В языке Java: (а + 1) <= а

20. Разработайте несложный класс Java для проверки утверждений (Ответ см. в Приложении В.)

24

Случаи, в которых используются исключения

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

retcode = OK;

if (socket.read(name)!=OK) {

  retcode = BAD_READ;

}

else

  processName(name);

  if (socket.read(address)!=OK) {

     retcode = BAD READ;

  }

  else {

     processAddress(address);

     if (socket.read(telNo)!= OK) {

        retcode= BAD_READ

   }

    else {

// etc, etc…

   }

  }

}

return retcode;

Но если язык программирования (no счастливой случайности) поддерживает исключения, то эту программу можно написать намного изящнее:

retcode = OK;

try {

  socket.read(name);

  process(name);

  socket.read(address);

  processAddress(address);

  socket.read(telNo);

// etc, etc…

}

catch (lOException e) {

   retcode = BAD_READ;

   Logger.log("Error reading individual;" +e.getMessage());

 }

return retcode;

Теперь схема управления отличается ясностью – вся обработка ошибок сосредоточена в одном-единственном месте.

Что является исключительным?

Одна из проблем, связанных с исключениями, заключается в том, что необходимо знать, когда их можно использовать. Мы полагаем, что не стоит злоупотреблять исключениями для нормального хода выполнения программы; они должны быть зарезервированы для нештатных ситуаций. Предположите, что неперехваченное исключение прекратит работу вашей программы, и спросите себя: "А будет ли эта программа исполняться, если удалить все обработчики исключений?". Если ответ отрицательный, то вполне возможно, что исключения используются в обстоятельствах, их не требующих.

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

Мы отвечаем следующим образом: "Это зависит от конкретного случая". Если файл должен был там находиться, то исключение гарантировано. Произошло что-то непредвиденное – файл, который вы считали существующим, похоже, исчез. С другой стороны, если вы понятия не имеете, должен ли этот файл существовать или нет, то его отсутствие уже не кажется столь исключительным и возвращение ошибки вполне уместно.

Рассмотрим пример с первой ситуацией. Представленная ниже программа открывает файл /etc/passwd, который обязан существовать во всех системах Unix. Если файл не открывается, происходит передача исключения FileNotFoundException к вызывающей программе.

public void open_passwd() throws FileNotFoundException {

//При этом может возбуждаться FileNotFoundException…

  ipstream = new FilelnputStream("/efc/passwd");

  //…

}

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

public boolean open_user_file(String name)

  throws FileNotFoundException {

  File f = new File(name);

  if (!f.exists()) {

     return false;

  }

  ipstream = new FilelnputStream(f);

  return true;

}

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

Подсказка 34: Пользуйтесь исключениями только в исключительных случаях

Почему мы предлагаем именно такой подход к исключениям? Конечно, исключение представляет собой мгновенную нелокальную передачу управления – своего рода многоуровневый оператор goto. Программы, использующие исключения в своей обычной работе, испытывают те же проблемы с удобочитаемостью и сопровождением, которые свойственны классическим неструктурированным программам. Эти программы нарушают инкапсуляцию: подпрограммы и их вызывающие программы отличаются более сильной связанностью за счет обработки исключений.

Обработчики ошибок как альтернатива исключению

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

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

Рассмотрим реализацию приложения «клиент-сервер» с использованием средства RMI (удаленный вызов метода) в языке Java. Поскольку RMI реализован определенным способом, каждое обращение к удаленной подпрограмме должно быть подготовлено, с тем чтобы обработать ситуацию RemoteException. Добавление программы обработки этих исключений может представлять собой утомительную процедуру и означает сложность написания программы, которая могла бы работать как с локальными, так и с удаленными подпрограммами. Обойти эту трудность возможно путем инкапсулирования удаленных объектов в класс, не являющийся удаленным. Тогда этот класс сможет реализовать интерфейс обработчика ошибок, позволяя программе клиента регистрировать подпрограмму, обращение к. которой происходит при обнаружении удаленной исключительной ситуации.

Другие разделы, относящиеся к данной теме:

• Мертвые программы не лгут

Вопросы для обсуждения

• В языках программирования, не поддерживающих исключительные ситуации, часто используется иной (нелокальный) способ передачи механизма управления (например, в языке С существует средство longjmp/setjmp). Подумайте, как можно реализовать некий «суррогатный» механизм исключения, используя указанные средства. В чем состоят преимущества и опасности? Какие специальные меры необходимо предпринять для гарантии того, что эти ресурсы не «осиротеют»? Есть ли смысл использовать подобное решение всякий раз, когда вы пишете программу на языке С?

Упражнения

21. При проектировании нового класса контейнера имеются три возможных состояния ошибки:

1. Не хватает памяти для нового элемента в подпрограмме add.

2. В подпрограмме fetch не обнаружена запрашиваемая точка входа.

3. Указатель null передан к подпрограмме add.

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

25

Балансировка ресурсов

"Я привел тебя в этот мир", – сказал бы мой отец, – "я же могу и отправить тебя обратно. Мне это без разницы. Я сделаю еще одного такого, как ты".

Билл Косби, Отцовство

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

Однако многие разработчики не имеют сколько-нибудь завершенного плана, касающегося распределения и освобождения ресурсов. Поэтому предлагается простая подсказка:

1 ... 30 31 32 33 34 35 36 37 38 ... 74
На этой странице вы можете бесплатно читать книгу Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант бесплатно.
Похожие на Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант книги

Оставить комментарий

Рейтинговые книги