|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
Automater При вот таком вот коде: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Пример странный, никакого смысла такой код не несет. Ну да ладно... :) Convert.ToInt32() и File.ReadAllText() (к примеру) будут выбрасывать совершенно разные типы исключений. Вот их и ловите по очереди, а в конце уже ловите общий Exception. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2008, 11:45 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
Диез будут выбрасывать совершенно разные типы исключений. Вот их и ловите +1 да, это 3-ий вариант. Раньше были go to всякие Есть библиотеки, которые не только стек отправляют, но и скриншот и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2008, 12:18 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
Диез Automater При вот таком вот коде: Вы получите ошибку 'Ошибка при чтении файла'. Т.е., в общем случае, трудно установить на какой строчке произошла ошибка. А если каждую строчку "окальцовывать" try-catch'ами, то код будеть выглядеть пугающе. Пример странный, никакого смысла такой код не несет. Ну да ладно... :) Convert.ToInt32() и File.ReadAllText() (к примеру) будут выбрасывать совершенно разные типы исключений. Вот их и ловите по очереди, а в конце уже ловите общий Exception.Мой шеф, любитель как раз таки этого подхода, именно этим и занимается. Прелесно смотреть на его список "потенциальных ошибок", который, естественно, не включает в себя весь спектр возможных. Конечно в итоге он ловит "общую" ошибку, если остальные не подошли, но смшно смотреть на то как человек мучается. Потом он ещё начинает изобретать свои классы исключений. Ведь надо же "вывалиться" из программы аварийным способом не только когда строчка не конвертится в число, а когда и процедура обращающаяся к базе вернула пустое множество, т.е. в случае логической ошибки. Ох, как жешь Билли заставляет людей раскорячиваться! Кроме того это не решает проблемы удобочитаемости кода. Обработки всевозможных ситуаций находятся на несколько экранов ниже, а не рядом с потенциально опасными строками. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2008, 23:40 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
Automater Ведь надо же "вывалиться" из программы аварийным способом не только когда строчка не конвертится в число, а когда и процедура обращающаяся к базе вернула пустое множество, т.е. в случае логической ошибки :) у кого какой бизнес. У некоторых он вываливается когда "база вернула пустое множество" :) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2008, 09:29 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
AutomaterМой шеф, любитель как раз таки этого подхода, именно этим и занимается. Прелесно смотреть на его список "потенциальных ошибок", который, естественно, не включает в себя весь спектр возможных. Конечно в итоге он ловит "общую" ошибку, если остальные не подошли, но смшно смотреть на то как человек мучается. Ну помучается, зато результат лучше будет. :) . По моему мнению, код метода должен ловить только те типы исключений, о которых он имеет четкое представление, откуда и почему они берутся. Остальные надо пробрасывать вверх, в вызывающий код - возможно, он знает, что с ними делать. Automater Потом он ещё начинает изобретать свои классы исключений. Ведь надо же "вывалиться" из программы аварийным способом не только когда строчка не конвертится в число, а когда и процедура обращающаяся к базе вернула пустое множество, т.е. в случае логической ошибки. Ну и что? Вы "оборачиваете" внешние исключения плюс логические ошибки - в коды возврата; он - их же оборачивает в бизнес-исключения, которые точно так же обрабатывает вызывающий код (совершенно необязательно вываливаться из программы при этом). В чем разница-то? Automater Ох, как жешь Билли заставляет людей раскорячиваться! Похоже, вы на Java не писали никогда. Вот где заставляют, так заставляют ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2008, 11:38 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
Диез Ну и что? Вы "оборачиваете" внешние исключения плюс логические ошибки - в коды возврата; он - их же оборачивает в бизнес-исключения, которые точно так же обрабатывает вызывающий код (совершенно необязательно вываливаться из программы при этом). В чем разница-то?В том что у меня код короче! Вопрос в стоимости поддержки софта, т.е. о количестве времени требуемом новому (или старому, но забывшему) программеру на то чтобы разобраться с логикой процедуры. Если обработка события стоит в catch'е на несколько экранов ниже, то проггеру придётся не сладко. Например: видит он багу что программа запихала в лог, лезет в код, ищет catch, находит, над catch'ем - пара экранов кода, и поди пойми какая строчка вывалила ошибку! Допустим пришла "ошибка конветации в число", а команд ToInt32() несколько - которая из них сбойнула? ДиезПохоже, вы на Java не писали никогда. Вот где заставляют, так заставляют Потому некогда и не пис а л Вот сегодня опять напоролся на необходимость реализации упомянутой мною системы (вывод в лог не только места где рухнуло, но и всех входящих параметров в ту процедуру, где произошёл эксепшн). Вижу у себя в логе, что пользователь Х. получил ошибку "clsDALBase.SafeExecuteStoredProcedure: The error description is 'An invalid character was found in text content.'. Could not find prepared statement with handle 3. The statement has been terminated." Явно при запаковке введённых текстовых данных в XML-строку туда проскочил какой-то нехороший символ, при распаковке посчитавшийся за специальный (управляющий). Но КАКОЙ ИМЕННО?! И вот мне, сегодня, пришлось напрягать главного инженера, чтобы он выяснил у инженера Х. что тот тогда вводил. Фантастика! Я задерживаю багафикс, трачу время на описание проблемы на английском, отвлекаю двух инженеров и всё только потому что у меня нет полной информации об ошибке. Вобщем, как я понял, несмотря на достаточно большой разброс в опыте среди присутствующих на этом форуме, никто и никогда вместе с информацией о точке где поизошёл эксепшн не выводил в лог информацию о том при каких условиях о произошёл (состояние входящих, и может быть некоторых локальных, переменных)? Ну тогда придётся опять самому крутиться... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2008, 21:53 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
AutomaterВопрос в стоимости поддержки софта, Какой же ты смешной.... AutomaterВобщем, как я понял, несмотря на достаточно большой разброс в опыте среди присутствующих на этом форуме, никто и никогда ... Читать ты за эти две недели так и не научился. P.S. Нехорошо, конечно, посвящать весь пост обсуждению личности и только личности, но других комментариев просто нет. Видать, это карма. Причем того, кому потом достанется возиться с этим, когдла ты свалишь. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2008, 22:52 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
Automater ...В том что у меня код короче! Нашли, чем хвастаться ;)) Шучу... Существует хорошая практика - делать код метода высотой не более полутора экранов. Сложные методы разбивать на несколько простых, а то и вообще выделять часть кода в отдельный Layer. Замечательный принцип. Причем, прекрасно работает и с эксепшенами, и с кодами возврата. Automater Вот сегодня опять напоролся на необходимость реализации упомянутой мною системы (вывод в лог не только места где рухнуло, но и всех входящих параметров в ту процедуру, где произошёл эксепшн). Вижу у себя в логе, что пользователь Х. получил ошибку "clsDALBase.SafeExecuteStoredProcedure: The error description is 'An invalid character was found in text content.'. Could not find prepared statement with handle 3. The statement has been terminated." Явно при запаковке введённых текстовых данных в XML-строку туда проскочил какой-то нехороший символ, при распаковке посчитавшийся за специальный (управляющий). Но КАКОЙ ИМЕННО?! И вот мне, сегодня, пришлось напрягать главного инженера, чтобы он выяснил у инженера Х. что тот тогда вводил. Фантастика! Я задерживаю багафикс, трачу время на описание проблемы на английском, отвлекаю двух инженеров и всё только потому что у меня нет полной информации об ошибке. Такая ситуация может возникнуть при любой архитектуре, это не показатель. А вот что, имхо, вам предстоит в ближйшем будущем: - сначала вам перестанет хватать Boolean на все случаи, вы переделаете коды возврата на Shortint - потом захотите возвращать еще и некую текстовую информацию, придется возвращать Record. - с увеличением уровней вложенности методов захотите разработать универсальный обработчик цепочки вызовов. - с удивлением обнаружите, что повторили модель исключений... Повторюсь, это имхо, просто сам через это прошел когда-то. softwarerВидать, это карма. Причем того, кому потом достанется возиться с этим, когдла ты свалишь. Резковато сказано, но +1 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 09:38 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
Диез Существует хорошая практика - делать код метода высотой не более полутора экранов. имхо это применялось для 'обзорности кода', когда студии имеют 'сворачивание кода' это менее актуально (например регионы, скобки ... в ms vs) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 09:44 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
KGP Диез Существует хорошая практика - делать код метода высотой не более полутора экранов. имхо это применялось для 'обзорности кода', когда студии имеют 'сворачивание кода' это менее актуально (например регионы, скобки ... в ms vs) Code folding - штука удобная, не спорю. Но, думаю, дело тут не только в обзорности, но и в структурировании кода. Например, некий метод должен загрузить платеж из базы, авторизовать его на удаленном вебсервисе и записать результат авторизации в БД. Логично будет вынести методы работы с БД и с вебсервисом в отдельные классы, тогда тело моего метода будет состоять просто из вызова трех внешних методов и обработки ошибок. Больше одного экрана вряд ли получится. И плюсы: - самодокументируемость кода, при наличии адекватных имен :) - удобство отладки - при возникновении эксепшена пишется Stack Trace в лог, а потом мы однозначно устанавливаем место возникновения ошибки по именам методов То есть идея такова, что если тело метода больше полутора страниц, то стоит задуматься о рефакторинге. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 10:44 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
ДиезCode folding - штука удобная, не спорю. Я, кстати, поспорю. Эта штука удобна имхо в двух случаях: 1. Плохой, нечитаемый код, из которого нужно убрать большую часть, чтобы не мешала мучительно разобраться в нужном куске. 2. Плохой, нечитаемый язык, который не отделяет декларации методов от их реализации, а следовательно не дает возможность увидеть интерфейс класса, забивая экран текстом методов. Ну а с code folding-ом видно хоть как-то, просто дополнительный мусор на экране. Имхо в обоих случаях нужно исправлять причину, а не подставлять костыль code folding-а. Что же до нормального кода - не припомню, чтобы возникало желание пользоваться сверткой. ДиезТо есть идея такова, что если тело метода больше полутора страниц, то стоит задуматься о рефакторинге. Только стоит помнить, что это именно "идея", а не безусловное правило. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 11:01 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
Диез Логично будет вынести методы работы с БД и с вебсервисом в отдельные классы, тогда тело моего метода будет состоять просто из вызова трех внешних методов и обработки ошибок. 1. а если и это будет 'более полутора экранов'? 2. а если завтра ваш экран будет 22', а не 17'? 3. как связано 'в отдельные классы', 'трех внешних методов' с 'более полутора экранов', почему не просто 3 отдельные функции того же класса? ps: мне не понятна роль аргумента 'более полутора экранов' ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 11:23 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
KGP ps: мне не понятна роль аргумента 'более полутора экранов' на камне написано: "Направо пойдешь - коня потеряешь. ". Нет, найдётся человек который неповерит :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 12:01 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
KGP Диез Логично будет вынести методы работы с БД и с вебсервисом в отдельные классы, тогда тело моего метода будет состоять просто из вызова трех внешних методов и обработки ошибок. 1. а если и это будет 'более полутора экранов'? 2. а если завтра ваш экран будет 22', а не 17'? 3. как связано 'в отдельные классы', 'трех внешних методов' с 'более полутора экранов', почему не просто 3 отдельные функции того же класса? ps: мне не понятна роль аргумента 'более полутора экранов' 1, 2. Естественно, полтора - это величина условная. Просто большая длина обычно требует более одного движения для полного обзора :) 3. Никто не мешает сделать методы того же класса, но часто удобнее и логичнее разнести код на уровни, т.е. в отдельные классы (а то и в отдельные библиотеки). Вообще, все это есть у Фаулера :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 12:11 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
Petro123 KGP ps: мне не понятна роль аргумента 'более полутора экранов' на камне написано: "Направо пойдешь - коня потеряешь. ". Нет, найдётся человек который неповерит :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 12:14 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
KGP2. а если завтра ваш экран будет 22', а не 17'? Насколько мне известно, споры "подпрограмма должна быть не больше сорока строк или все же можно до пятидесяти" шли еще в шестидесятые года прошлого века. Думаю, что и в шестидесятом веке будут ломать копья об аналогичном в целом вопросе ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 12:34 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
softwarer Насколько мне известно, споры "подпрограмма должна быть не больше сорока строк или все же можно до пятидесяти" шли еще в шестидесятые года прошлого века. Думаю, что и в шестидесятом веке будут ломать копья об аналогичном в целом вопросе если нет ООП-предпосылки к разбиению, а лишь проблема в не_возможности_одним_вглядом_охватить_нечто, то почему и не ограничится применением Code folding? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 12:52 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
что есть "ООП-предпосылка" и чем она важнее, нежели желание видеть весь код метода без всяких разных свёртываний? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 13:10 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
softwarer ДиезCode folding - штука удобная, не спорю. Я, кстати, поспорю. Эта штука удобна имхо в двух случаях: 1. Плохой, нечитаемый код, из которого нужно убрать большую часть, чтобы не мешала мучительно разобраться в нужном куске. 2. Плохой, нечитаемый язык, который не отделяет декларации методов от их реализации, а следовательно не дает возможность увидеть интерфейс класса, забивая экран текстом методов. Ну а с code folding-ом видно хоть как-то, просто дополнительный мусор на экране. Имхо в обоих случаях нужно исправлять причину, а не подставлять костыль code folding-а. Что же до нормального кода - не припомню, чтобы возникало желание пользоваться сверткой. С первым пунктом согласен на 100. А по второму все-таки выскажу соображения (не холивара ради :)) ) Если мы пользуемся текстовым редактором, то да - паскаль и си дадут фору в плане читабельности интерфейсов жаве и шарпу. Но в современных IDE эта разница нивелируется. В конце концов, это дело привычки: нажимать Ctrl-Shift-Up/Ctrl-Shift-Down в Delphi IDE, или Ctrl-M,Ctrl-O/Ctrl-M,Ctrl-P в Visual Studio. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 13:11 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
ДиезНо в современных IDE эта разница нивелируется. Бесспорно, нивелируется. Тем не менее я вижу разницу между "полезной фичой IDE, реально делающей жизнь лучше" и "костылем, который IDE подставляет там, где кто-то схалтурил". По мне code folding куда ближе ко второму варианту. А такие фичи мне не очень нравятся, так как их наличие провоцирует дальнейшее нарастание кривых решений: мол, сделаем плохо, а IDE потом будет нивелировать. Я вовсе не призываю программировать в notepad-е, но полагаю, что уход от него должен осуществляться там, где оно стоит и так, чтобы стоило. Простейшим примером назову visual diff: делая check in / check out, я заинтересован в том числе компактно и четко увидеть "что поменялось в интерфейсе класса", и code folding мне здесь не сказать, что поможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2008, 15:44 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
softwarer Я вовсе не призываю программировать в notepad-е, но полагаю, что уход от него должен осуществляться там, где оно стоит и так, чтобы стоило. Простейшим примером назову visual diff: делая check in / check out, я заинтересован в том числе компактно и четко увидеть "что поменялось в интерфейсе класса", и code folding мне здесь не сказать, что поможет. Да, в простых случаях такой подход сработает. Но в общем случае diff сравнивает текст внутри файла, но отнюдь не языковые элементы. В приложении небольшой пример, который покажет совсем не то, что вы ожидаете. А если методов штук тридцать, да еще меняются модификаторы видимости?.. Так что, ИМХО, в вашем примере с diff, отделение интерфейса от реализации - скорее недостаток языка, позволяющий незаметно выстрелить себе в ногу. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2008, 12:36 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2008, 12:37 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
ДиезДа, в простых случаях такой подход сработает. Да и в остальных тоже недурен. ДиезНо в общем случае diff сравнивает текст внутри файла, но отнюдь не языковые элементы. Есть такое. Поэтому я с большим скепсисом отношусь к различного рода "автоматическому слиянию" итп. Но информацию для глаз он дает вполне адекватную. Не идеальную, но - о чем Вы, похоже, забыли - кардинально лучшую, нежели полнейшее ее отсутствие . ДиезВ приложении небольшой пример, который покажет совсем не то, что вы ожидаете. Любопытно, откуда Вы знаете, чего я ожидаю? :) Даже если diff не из самых навороченных и не умеет правильно показывать перемещенные строки, не вижу в том проблемы. Суть Вашего примера любой из присутствующих поймет за несколько секунд - что, обратите внимание, как раз и требуется. ДиезА если методов штук тридцать, да еще меняются модификаторы видимости?.. И что страшного? Хоть триста. ДиезТак что, ИМХО, в вашем примере с diff, отделение интерфейса от реализации - скорее недостаток языка, позволяющий незаметно выстрелить себе в ногу. Простите, но пока как минимум эта фраза, сказанная оторванно от какого бы то ни было обоснования. "diff в некоторых случаях неидеален" - принимается. "Поэтому не лучше" - не соглашусь, но логику пойму. А вот "выстрелить себе в ногу" Вы взяли просто с потолка. Фразу "отделение интерфейса от реализации - скорее недостаток", как Вы понимаете, есть желание вырезать, повесить на стенку и цитировать :) На самом деле, я бы сказал, недостатком языка (дельфы) является как раз недостаточное их отделение, в частности, потребность описывать private часть публичного класса в interface секции модуля. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2008, 15:56 |
|
Отправка отладочной информации саппорту?
|
|||
---|---|---|---|
#18+
[quot Диез А вот что, имхо, вам предстоит в ближйшем будущем: - сначала вам перестанет хватать Boolean на все случаи, вы переделаете коды возврата на Shortint - потом захотите возвращать еще и некую текстовую информацию, придется возвращать Record. - с увеличением уровней вложенности методов захотите разработать универсальный обработчик цепочки вызовов. - с удивлением обнаружите, что повторили модель исключений... Повторюсь, это имхо, просто сам через это прошел когда-то. [/quot] Boolean сразу не хватает на все случаи жизни. За код возврата BOOLEAN сразу бы руки отрубал. У меня вот нету эксепшенов (точне есть, но такие, скромные), так что приходится строку вверх гнать. По пути она обрастает описанием с каждой кокретной точки и, в итоге, видно, путь на котором "сломалось". Удобно. А проверять надо _все_ ибо сломаться может в любом месте, даже там, где, казалось бы, ничего не грозило... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2008, 21:10 |
|
|
start [/forum/topic.php?fid=33&msg=35273309&tid=1548793]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 286ms |
total: | 415ms |
0 / 0 |