Petro123maytonили парадигма кодинга продолжает использоваться и в настоящее время.
это только для узких случаев:
- стека практически нет. Один уровень в main
стек здесь возникает на каждом вызове библиотечной процедуры.
Petro123- БЛ нет и управлять исключительными ситуациями не надо. Весь код не делает ничего интересного кроме выплёвывания ошибок в выходной поток.
Бизнес логика здесь состоит в передаче текста переданного в качестве параметра сообщения на указанный во входном же параметре хост. Это код и делает. А "выплевывание" чего-то во входной поток - это
побочный результат деятельности функции.
В общем случае
страшно порицаемый изобретателями методик "структурного" программирования.
Petro123- т.к. высокая производительность, то в жертву принесено всё остальное удобство от ООП до try и т.д. т.п.
как можно принести в жертву "удобство ООП" в языке, который про "ООП" ничего не знает?
Это как Ликург в Спарте в 8м веке до нашей эры принес в жертву удобство использования криптовалюты в интернете,
методом запрета денег, сделанных из золота.
В жертву здесь принесена возможность использования представленной функции в сколько-нибудь развитых скриптах автоматизации. Путем возложения на саму функцию задачи "выплевывания" чего-то в выходной поток.
Что при другом заходе должно было бы стать обязанностью того самого скрипта.
Petro123ЗЫ
Прикладной код с поведением пишется совсем по другому.
У данного кода только 2 состояния - ВКЛ\ВЫКЛ
Такое вполне можно применять напр. при сериализации. Будет 2 состояния: Поучилось и НЕполучилось.
Вы ошибаетесь. В смысле выходного состояния у этой функции
одно состояние. Всегда ВКЛ. Все получилось.
Могло бы быть и два и больше - прямо по тексту вычитывается как минимум пять разумных состояний возврата,
но автор кода решил обойтись одним.
Принципиально в контексте обсуждения именно checked exceptions не вопрос о том - является ли здесь выдача единственного результата ошибкой программирования (имхо - является, но не это критично важно для безопасного программирования),
а вопрос о том, не разрушается ли весь локальный мир всего того адресного пространства в котором запускается этот код при неудачном вызове.
И ближайшим кандидатом на разрушение мира в этом коде является фрагмент
1.
2.
3.
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0)
error("ERROR opening socket");
в котором не происходит попытки закрыть неудачно открытый сокет.
Просмотра только этого фрагмента в общем случае недостаточно, чтобы дать ответ - идет здесь речь о прямой ошибке программирования или нет.
Потребуется знание не только реализации функции socket, но и знание деталей устройства конкретной операционной системы,
в рамках которого код может оказаться вполне безопасным в смысле блокировки/потери ресурса.
Вероятно, рассматривание кода примерно такого сорта сорта и должно наводить на желание вписать прямо в контракт функции socket
обязанность по обработке контролируемого исключения.
Но ровно этот же код и показывает пример того, насколько бесплодна затея,
если программист поставил себе твердую цель потушить полученную информацию методом недеяния, игнорирования результата.
(Зачем-то для чьих-то досужих глаз записывая некий мусор в лог.
Конечно, когда система полностью встанет от полной блокировки ресурсов - появится заинтересованный читатель полученных логов с приветами от программиста.
А вот у этого заинтересованного читателя ответить письменным образом "в лог программисту" может не оказаться возможности.)
