Сегодня была обычная "корка" от программеров:

Достаточно процесс длительный (часов на 19) формирования отчетных файлов по клиентам (почти 100тыс XLS-файлов в итоге). Приложение "пережовывающие" SQL-базу вывалило "Ассess violation". В логах тишина. Только копание в логах винды позволило понять, что сетевая "шара" (куда файлы с отчетами кладем) отвалилась.

Что мешает программеру каждый свой шаг бизнес логики обложить "траями" (try..entry)?

Ищу имя клиента из БД
смог: идем дальше
не получилось: в лог кладем, что искал, что случилось и кого известил. А пользователю в мессадже рассказать на человеческом языке... я не стеком вызова функций.

Это трудно?! Какой смысл вываливать дельфийский "Access violation" пользователю ?

Это что, наплевательское отношение к своей работе или каждого программера служба поддержки должна "подвести к обоссанному тапку и окунуть в него мордой"?





Исправлено 4 раз(а). Последнее : Vedmak, 07.09.17 00:43

Каждую команду программы нереально обвешать TRY..ENDTRY (и написать человеческое сообщение по ошибке)

В фоксе (и во всех языках "высокого" уровня) есть перехват ошибки (т.е. в любой строке проги может возникнуть "прерывание-ошибка"). И опять же, написать вменяемое сообщение об ошибке на основе номера строки проги, и даже текста ошибочной строки, тоже нереально. Кстати в фоксе из этого "прерывания" можно выйти не RETURN (продолжение программы с следующей строки), а RETRY (повторить ошибочную строку и продолжить) - полезная штука. Например, прога хочет писать в файл XLS, а этот файл открыт юзером. Прога прерывается, пишет типа "нет доступа к файлу имя такое-то", умный юзер закрывает файл, и нажимает RETRY.

А бизнес-логика обычно (если хватает времени разрабу) конечно обкладывается "TRY..ENDTRY", или, например, функция "ВыполнитьНачисление" возвращает не всегда .T., а флаг успешности, или вообще - текст о примерных причинах ошибки...

Vedmak
Что мешает программеру каждый свой шаг бизнес логики обложить "траями" (try..entry)?

Зачем!? Времени, чтобы "настичь мясо в лесу" совсем не останется же.

как мне нравилось в этом отношении подход
on error
по весил в одном месте - написал в 1 месте всю логику и все

по поводу отвиса шары - имхо не очевидная ошибка сети
путь обычно задается допустим в настройкха - м.б c:\
а может быть и сетевоей
в фоксе помнится выдавало что-то типа File Read Error

ps я бы сказал что каждый шаг обвязывать Try это не совсем правильно
но тут наверно что-то могут сказать больше java или C прогеры



Исправлено 2 раз(а). Последнее : Гулин Федор, 07.09.17 11:54

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

P.S. В фоксе "в принципе" подобная ситуация (отказ накопителя - сетевого, локального - не суть важно) запросто может закончиться c005, опять же без "вменяемого сообщения об ошибке".

Гулин Федор
как мне нравилось в этом отношении подход
on error
по весил в одном месте - написал в 1 месте всю логику и все

Это хорошо/удобно исключительно для регистратора "необрабатываемых ошибок" (там где и реакции никакой нет - тупо записать в лог проблему и сказать юзеру "превед"). Для вменяемой обработки ОЖИДАЕМЫХ исключений глобальный ON ERROR крайне неудобен. Всё это мозгоё***о с lcOldOnError = ON("ERROR"), ON ERROR &lcOldOnError - убогий костыль.

Гулин Федор
по поводу отвиса шары - имхо не очевидная ошибка сети

Именно так - эти ошибки НЕ обрабатывают (в смысле не предусматривают специальную реакцию на такого рода системные проблемы). А касательно 19-часового отчёта - ну я бы и для менее глобальных процессов вёл "лог исполнения" - по крайней мере видна будет сделанная часть работы, и примерно понятно на каком этапе всё "сломалось". Это НЕ тема обработки ошибок, конечно, но для пакетных/автоматических программ очень хороший "шаблон проектирования".

Гулин Федор
в фоксе помнится выдавало что-то типа File Read Error

В лучшем случае...

Гулин Федор
я бы сказал что каждый шаг обвязывать Try это не совсем правильно

try это "вложенные" обработчики ошибок. Формально в нормальной программе с try...catch обработкой ошибок ЛЮБАЯ "рабочая" команда находится внутри блока try - обычно даже внутри НЕСКОЛЬКИХ таких вложенных блоков. Вне программных try находится только сам внешний обработчик ошибок (блок catch или finally) - но даже для этих ситуаций (ошибка внутри обработчика ошибок) могут быть предусмотрены свои "средства разруливания".
Вот оборачивать каждую отдельную команду в свой try - да со всеми 100500 catch-ами (на каждое теоретически возможное исключение) - так, естественно, никто не делает. Ловят и обрабатывают только то что "ожидают" для данного блока кода. Всё прочее "проваливается" на уровень выше - и так вплоть до самого верхнего "глобального" catch - тот уже ловит всё, но не обрабатывает, а просто записывает суть проблемы и закрывает программу.

Vedmak
Это что, наплевательское отношение к своей работе или каждого программера служба поддержки должна "подвести к обоссанному тапку и окунуть в него мордой"?

Это менеджер, ежечасно требующий от программера отчёт о работе. Такой, чтобы его можно было показать старшему менеджеру, т.е. "написал обработчик системных ошибок FoxPro с кодами 108 и 109" - не прокатит.

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

1. В справочнике есть поле, значением которого может быть список календарных периодов. Если хотя бы одна запись содержала список из более чем одного элемента, то справочник нельзя было ни напечатать, ни сохранить в файл - на экран выводилось замечательное по своей полезности сообщение "Ошибка в строке 10". Написал в службу поддержки. Ответ: "В справочнике всего 24 записи, вы можете переписать их вручную"

2. При вводе табельных номеров в табеле подразделения не проверяется принадлежность номеров этому подразделению. Разработчик по телефону сказал: "Если вводить правильные табельные номера, проблема есть? Нет. Вот и вводите без ошибок". Через некоторое время пришёл письменный ответ от аналитика, с которым мы писали ТЗ на этот табель (в ТЗ контроль принадлежности табельных номеров подразделению был): "Правильный данных нужно вводить, а не искать программный ошибка"

Igor Korolyov
А касательно 19-часового отчёта - ну я бы и для менее глобальных процессов вёл "лог исполнения" - по крайней мере видна будет сделанная часть работы, и примерно понятно на каком этапе всё "сломалось". Это НЕ тема обработки ошибок, конечно, но для пакетных/автоматических программ очень хороший "шаблон проектирования".

Тут я бы добавил - при повторном запуске 19-часового отчёта должна быть возможность старта с точки перед сбоем. При генерации 100 тысяч файлов таких точек не может не быть. Иначе клиенты отчётов не дождутся. Но разработчики программ на такие предложения обычно реагируют длинными речами об утрате актуальности данных и необходимости "всё пересчитать".

Это всё "зависит от ..."
Есть мега-отчёты которые нельзя "перезапустить с точки сбоя", есть которые можно. Смотря как спроектирована система (БД в первую очередь).

А по поводу "контроля ввода" - ну вот ты грамотный пользователь - просишь пожёстче контроль. Но большая часть пользователей таки обратного просят - обязательное для заполнения поле? Нет, убери, позволь держать в базе 50 пустых записей "на всякий случай". Дата вводимая через календарь и именно как дата - нет, позволь всякую хрень писать типа "после дождичка в четверг" - "в экселе ж можно" - железный аргумент
Вообще абсолютно все "пожелания" пользователей должны проходить через вдумчивую "обработку" аналитиком/постановщиком - т.к. если немедленно всё реализовывать, то такую кучу #$%^& вместо программы получишь, что проще будет всё выкинуть и начать с нуля писать потом

Цезарь
...

Igor Korolyov
...

of63
...

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

Именно служба поддержки видит то, чего одни недофантазировали (не задокуменировали), другие не досозодали (поленились логами обложить), а третьи суют (не прочитав документацию по изделию) раскаленный стержень себе в ухо.

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

Пример из моего PHP проекта (извините за идейное предательство). Это метод одного из классов... По бизнес логике в случае ошибки в лог каждый метод укажет свои 5 копеек в качестве мнения о ошибке.


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

В идеале ни одно решение не должно умирать наступив на грабли при выполнении задания. Любая ошибка должно выводить приложение на уровень с которого процесс запустили. Пользователь набирал метровую накладную и нажал "сохранить". При этом экскаваторщик оборвал кабель и БД отвалилась. Пользователю должно быть сообщено о том, что при сохранении документа возникли технические проблемы и он должен быть оставлен в рамках функционируещего приложения, а не быть окунутым в грязь фатальной ошибкой которая означает потерю его часовой работы. В идеале пользователю можно предложить сохранить его работу во временном файле и его потом востановить в приложении.

Я так вижу!






Исправлено 1 раз(а). Последнее : Vedmak, 07.09.17 21:52

Vedmak
Сейчас для меня это хобби

Вздохнул с облегчением

Ожидаю ответа от тех кто "не выпускает воздух".





Исправлено 1 раз(а). Последнее : Vedmak, 08.09.17 22:58

Пардон, уж не знаю в тему ли... ;)

Буквально пару недель тормошит меня одна маленькая фирма. На двух компах пропали ярлыки на мою программу после пропадания электричества.
Я им про админа толковал все это время. А админ тамошний сынок одной работницы, которая к тому же и соучредитель.
И ни в какую. Я им про папку Programm Files и далее.. и наличие файла setup.exe на сервере и... Ну никак.
Пришлось заскочить.
На рабочем столе ярлык с иконкой от "Мой компьютер", но с названием от моей программы.
В ярлыке пути к моей папке прописаны. Открываю эту папку показываю девчёнкам содержимое. Все видят знакомую мою иконку.
"Отправить на рабочий стол (создать ярлык)". Всё.

В процессе узнаю, что если пропадает электричество (иногда просто моргнет), то сервер перегружается 40 минут.
Все это время могут быть клиенты, но основная программа и 1С не доступны.
40 минут грузится сервак?!
И перегружается от моргания света?!
Причем хозяева фирмы в этом кабинете находятся постоянно и сами работают. И финансами рулят.
С этой конторой сотрудничаю как минимум с 2005 года. Ранее 3 человека из них, в том числе хозяева работали в другой конторе также со мной.
И никак ничего им не объяснить.
Пришлось за два "Отправить на рабочий стол..." взять денег чуть более чем достаточно. Ну чисто для стимуляции.
Отказать не могу. Ибо добрейшей души человек.

++
Ну и конечно несколько веселят на каждом компе ярлыки "olga", "vera", "ira" и пр..
Тупо ссылка на соседние компы, корень диска C.
А потом как-то уж там ищут документы...

Vedmak
Пример из моего PHP проекта (извините за идейное предательство). Это метод одного из классов... По бизнес логике в случае ошибки в лог каждый метод укажет свои 5 копеек в качестве мнения о ошибке.

public function connect($host = "127.0.0.1", $port = 60000) {
        log_write( "Connect to ".$host.":".$port );
        if ( !parent::connect($host, $port) ) {
            log_write( parent::error_msg() );
            return ( $this->error_id == no_error );
        }

        if ( !$this->identify() ) {
            log_write( $this->error_msg() );        
            return ( $this->error_id == no_error );
        }
        
        return ( $this->error_id == no_error );
    }

Это да, для ДВУХ строк кода нарисовать метод на десяток строк, и всё это на интерпретируемом языке...
Внутри log_write да identify тоже, поди, каждое примитивное действие обвешано таким же мусором
Но ничё, компы нынче быстрые, памяти много... Непонятно только зачем было своё время тратить на писание лишних строк кода, когда можно было его с гораздо большей пользой потратить на зарабатывание монет





Исправлено 1 раз(а). Последнее : Igor Korolyov, 09.09.17 13:31

Есть такой классный мульт "Крылья, ноги и хвосты".

"Лучше день потерять, а потом за пять минут долететь".

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

Я клиента успокою. А потом перейду к раскалению углей на которых кодер будет отвечать на мои вопросы.





Исправлено 2 раз(а). Последнее : Vedmak, 09.09.17 20:26

Vedmak, ты из разрабов попал в службу поддержки что ли?

Божья_коровка
Vedmak, ты из разрабов попал в службу поддержки что ли?

Я не "попал", а создал. Кодеры без хлыста краев не знают. Я рассказываю мастерам чего и куда они могут свое мастерство применить.

Когда кодер без пригляду творит у него плохие привычки рождаются....






Исправлено 1 раз(а). Последнее : Vedmak, 09.09.17 20:32

Как в той старой шутке
"Кто умеет - делает, кто не умеет - руководит, а кто и руководить не умеет - учит других"

Чем больше лог, тем меньше в нём толку, т.к. найти в километровой простыне причину возникшей проблемы не сильно проще, чем найти её вообще без лога.

Обвешивать каждый чих проверками/логами - это форменное безумство. Да, возможно в софте для автопилотов авиалайнеров или управляющей программе АЭС это и будет выглядеть нормально и адекватно, но в прикладном софте для обычных тупых юзеров - ну если очень мягко сформулировать, то просто явный перебор.

TeamViewer РУЛИТ
ПОСТАВИЛ и все - где коненчо это позволительно
случай описанный Taran с ним лечитися за 5-10 мин

насчет логов - если ты САМ писал эти логи - да есть вероятность чего то найти
а если логи писали др. девелоперы - так вероятнсоть резко уменьшается
имхо где то 50 на 50 как всегда

Гулин Федор
имхо где то 50 на 50 как всегда

Как в том анекдоте про блондинку - вероятность встретить на улице живого динозавра...