К> Несколько оффтоп, но поражает насколько наши программисты английского не К> знают... Может несколько резко, но меня лично вот от таких названий К> "коробит".
С другой стороны, даже если поправить название:
bool doesPersonExist( String name );
при использовании в коде лучше не будет:
if ( doesPersonExist( "Tom" ) )
...
Ну не говорят так
Мне больше нравится так:
if ( person_exists( "Tom" ) )
...
С другой стороны, все равно найдется случай, где любое название будет выглядеть
не на месте с точки зрения английского.
Соответственно, можно расслабиться, и относиться к названиям не как к английскому,
а как к некоторому набору соглашений, где из английского взяты только слова, а их
комбинация подчиняется совсем другим правилам.
Поэтому все это суть личные предпочтения...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>dshe,
ПК>В C++ я предпочитаю такой вариант: ПК>
ПК>boost::optional< Person >
ПК>findPersonByName( std::string name );
ПК>
ПК>или, для C#: ПК>
ПК>Person?
ПК>findPersonByName( string name );
ПК>
ПК>или (вот здесь я уже не вполне уверен, можно ли на Java так сделать -- ПК>если нет, тем хуже для Java ): ПК>
ПК>Optional<Person>
ПК>findPersonByName( String name );
ПК>
ПК>И не нужно никаких лишних комментариев и, тем более, исключений.
Насколько я понял, в твоем варианте вместо Person возвращается нечто, из чего потом можно Person'а получить. И именно то, что экземпляр Person'а не доступен сразу, является напоминанием программисту о необходимости проверки полученного из findPersonByName результата. Что ж, тоже вариант.
Приведу еще один небольшой аргумент в пользу исключений. Исключения могут с собой нести некоторую дополнительную информацию. Например, PersonNotFoundException мог бы содержать имена существующих людей, которые наиболее близки к искомому. Эту информацию можно было бы использовать для того, чтобы помочь пользователю в его поиске. Признаюсь, я очень редко пользовался этой возможностью и еще реже видел, чтобы класс исключения (написанный не мной) содержал в себе что-то более чем error message.
ПК>Случай с использованием исключений внутри функции реализуем, но приводит к ПК>изменению структуры кода, а в случае с несколькими объектами -- к его усложнению ПК>и запутыванию.
ПК>Случай с передачей аргументов исключениями не выражается, что демонстрирует ПК>плохую масштабируемость подобноо подхода.
На мой взгляд, использование Optional<?> не отрицает использования исключений.
Здравствуйте, VladD2, Вы писали:
C>>Нужно следить не столько за типами исключений, сколько за возможностью C>>вылета "прикладных" исключений. То есть не логических ошибок в коде, а C>>исключительных ситуаций в процессе работы.
VD>Вот за "прикладные исключения" нужно морду бить. Причем сильно и жестоко.
А куда же без них в серверном приложении? У тебя есть сервер, кто-то вызывает методы, параметры не так передал или просто невовремя вызвал метод, или операцию нельзя совершить... — серверу только и остается, что плюнуть ексепшеном в вызывателя.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VladD2, Вы писали:
ПК>>>Т.е. логические ошибки и исключительные ситуации в этом отношении ты не разделяешь?
VD>>Это еще почему? Логические ошибки вообще контролировать нельзя. На то они и ошбки. Если ты о незапланированных исключениях, то это данность. И боросться с ней нужно только там где без этого никак.
IT>Речь скорее всего о софте, который обязан работать 24x7 в любых условиях. Например. софт для 911. Но это совершенно отдельный класс задач, который решается не обработкой всех подряд типов исключений, а, в том числе, написанием софта, который следит за работоспособностью основного софта.
IT>А обработка всех подряд типов исключений...? Я просто не понимаю что с ними потом делать
Ничего... Часто эти ексепшены в иерархии организованы, так что "мелочиться" на каждый эксепшен и не обязательно.
Здравствуйте, dshe, Вы писали:
IT>>Кроме того что упомянул Павел (неочевидность кода) можно добавить ещё то, что в больших количествах исключения существенно подтормаживают скорость выполнения приложения.
D>Согласен. Производительность может существенно повлиять на дизайн. Тем не менее не только исключения влияют на производительность в худшую сторону, но и такие вещи как reflection или даже виртуальный вызов. Но это не повод их избегать.
Я специально подчеркнул — в больших количествах. Точно так же именно в больших количествах и reflection может оказаться узким местом приложения. Одно дело когда исключения используются по назначению, например, даже для той же валидации ввода пользователя. В такой цепочке как браузер -> интернет -> лоад-балансер -> IIS -> ASP.NET -> твой код -> база данных -> исключение -> и поехали обратно, влияние одного исключения на весь процесс ничтожно мало и учитывать его время в данном случае просто смешно. Другое дело, когда дело дошло до твоего кода и в одном запросе он начал плодить и тут же душить исключения тысячами. Можешь проверить, задержка будет существенной, особенно при большой нагрузке.
D>Могу еще добавить, что исключения должны возникать в исключительных ситуациях.
Именно.
D>Но на мой взгляд, не всегда исключительная ситуация это именно ошибка.
Можно упростить все эти терминологические изыскания. Исключение должно применяться в том случае, если программа не может продолжать своего выполнения. По какой причине — это уже не важно.
D>Я тоже так иногда делаю когда пользуюсь debugger'ом. Правда, breakpoint обычно ставлю только на unchecked исключения. Но чаще просто смотрю в логи -- stacktrace'ов бывает достаточно, чтобы понять где и какая ошибка произошла.
stacktrace — это хорошо. Но часто для выяснения причины нужен контекст выполнения. В отладчике можно подняться на несколько вызовов выше и всё подробно исследовать. В общем, с этой фичей поиск причины неполадки является довольно простым занятием.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
IT>>А обработка всех подряд типов исключений...? Я просто не понимаю что с ними потом делать
V>Ничего... Часто эти ексепшены в иерархии организованы, так что "мелочиться" на каждый эксепшен и не обязательно.
Об этом и речь. Записали в лог или показали пользователю и забыли.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT wrote:
> C>Интересно, считать ли исключение об ошибке открытия файла — > "прикладной" ошибкой? > Твоя программа может после этого продолжать выполнение?
Здравствуйте, dshe, Вы писали:
D>В этом варианте PersonFinder возвращает null если человек не был найден. При этом вызывающий код обязан проверить полученный результат на null. Причем, он обязан исходя из неявного соглашения описанного в комментариях, которые не все и не всегда читают и пишут. Компилятор не выдаст ни error'а, ни warning'а если результат не будет проверен на null. Это основной недостаток данного подхода.
Думаю, это надуманный недостаток. Обычно такие недостатки легко выявляются на стадии тестирования.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Cyberax, Вы писали:
>> C>Интересно, считать ли исключение об ошибке открытия файла — "прикладной" ошибкой? >> Твоя программа может после этого продолжать выполнение?
C>Может, причем инварианты не нарушаются.
Тогда это штатная (ожидаемая) ситуация для твоей программы и можно вполне обойтись без исключения.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
VD>>Вот за "прикладные исключения" нужно морду бить. Причем сильно и жестоко.
V>А куда же без них в серверном приложении? У тебя есть сервер, кто-то вызывает методы, параметры не так передал или просто невовремя вызвал метод, или операцию нельзя совершить... — серверу только и остается, что плюнуть ексепшеном в вызывателя.
Речь в данном случае о другом. Речь о ситуации, когда сервер "выплёвывает" и тут же сам это хозяйство ловит, типа обрабатывает.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT wrote:
>>> C>Интересно, считать ли исключение об ошибке открытия файла — > "прикладной" ошибкой? >>> Твоя программа может после этого продолжать выполнение? > C>Может, причем инварианты не нарушаются. > Тогда это штатная (ожидаемая) ситуация для твоей программы и можно > вполне обойтись без исключения.
И возвращать код ошибки через 5-6 уровней? Нет уж, спасибо.
Здравствуйте, IT, Вы писали:
ПК>>Если, конечно, приложение надежно (умеет не терять данные при всевозможных сбоях, и не только программных).
IT>Паша, читай более подробно о stateless. Правильные stateless приложения не теряют данные, т.к. им нечего терять.
Хм... Современные "правильные" приложения состоят из многих составляющих, иногда физически распределенных. Скажем, у нас есть stateless-сервер. Ok. Но клиент набивал длинный текст в окошке GUI. Форма GUI не может быть полностью stateless (по крайней мере это труднодостижимо — скидывать на диск по каждому событию типа OnChar или OnClick). Далее, при ошибке сохранения данных формы на сервер, было бы неплохо не потерять введенные пользователем данные. Ошибка могла возникнуть не только по причине отсутствия связи. Все гораздо интересней, если связь есть, но сервак выплевывает ошибку. Наверно, Пашин совет касается подобных вещей.
---------
В нашей системе мы используем 2 корня иерархии ошибок: LogicError и RuntimeError. Первый случай описывает логические ошибки пользователя системы (неккоректные данные или действия). Второй тип ошибок — это ексепшены, выкинутые не прикладным кодом. Т.е. ошибка произошла "сама по себе" (Ресурсы или ОС виноваты) или по вине программиста. Пытаться что-то сделать при этом обычно бесполезно, как раз нужно на клиенте сохранить текущий контекст, на сервере сохранить подробный лог и stack-trace и закрыть данную клиентскую сессию с аккуратной прочисткой ресурсов, ибо последующее взаимодействие клиента с сервером в рамках той же сессии может привести к непредсказуемым результатам (если ошибка произошла по вине программистов).
IT>В случае серверных приложение это тем более неверно. Серверный (да даже просто бизнес код) вообще не должен обрабатывать никаких исключений. Разве что только для логирования, да и то я бы это обсудил. Исключение из бизнес кода должно сквозняком улетать пользователю в первозданном виде. Сервер не должен пытаться его каким-то волшебным образом обработать. Это не его (простите мне мой французский) собачье дело. Не справился с поставленной задачей — доложи тому кто тебя тебе эту задачу поручил.
Это иногда невозможно, если у нас гетерогенная среда (CORBA, например). Мы вынуждены ловить ексепшены, чтобы "завернуть" их в транспортный вид.
IT>Другими словами — контекст вызова умирает вместе с вызовом и никаким существенным образом на работоспособность сервера это влиять не должно ни при удачном, ни при не очень исходе.
Тоже не все так просто. В нашей системе редактируется некая сущность. Затем вызывается процедура валидации данных. Процедура сложная и зависит от многих вещей — короче, делаем валиадцию на серваке. Результат валидации — не просто yes/No — а тоже вполне осмысленный набор записей. И вот что характерно — мы хотим валидировать подобным образом текущие редактируемые данные ДО сохранения в базе. И как тут поможет stateless?
Здравствуйте, vdimas, Вы писали:
V>Хм... Современные "правильные" приложения состоят из многих составляющих, иногда физически распределенных. Скажем, у нас есть stateless-сервер. Ok. Но клиент набивал длинный текст в окошке GUI. Форма GUI не может быть полностью stateless (по крайней мере это труднодостижимо — скидывать на диск по каждому событию типа OnChar или OnClick).
— моя первая реплика.
V>Далее, при ошибке сохранения данных формы на сервер, было бы неплохо не потерять введенные пользователем данные. Ошибка могла возникнуть не только по причине отсутствия связи. Все гораздо интересней, если связь есть, но сервак выплевывает ошибку. Наверно, Пашин совет касается подобных вещей.
Согласись, что сохранение данных формы — это не дело сервера.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Cyberax, Вы писали:
>> C>И возвращать код ошибки через 5-6 уровней? Нет уж, спасибо.
Да, извини, просто ты сам вполне однозначно ответил на свой вопрос.
Я уже тут не раз говорил, что из двух подходов лучше тот, прикладной код для которого проще. Если тебе не удобно протягивать резалт коды через 5-6 уровней, то конечно же используй то, что тебе удобнее. На самом деле я не раз убеждался в том, что слепое следование теории и "общепринятым" правилам в программировании, области человеческой деятельности, у которой практически ещё нет истории и сложившихся методик, чаще приводит к казусам, чем к правильному результату.
По-этому, повторюсь ещё раз: хорошее решение должно порождать простой прикладной код, очень хорошее – очень простой, а идеальное решение – синоним примитивного кода. И не слушай никого
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
