Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Разработка информационных систем Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3      [все]
 Отправка отладочной информации саппорту?  [new]
Automater
Member

Откуда:
Сообщений: 146
Когда в Windows падает какая-то майкрософтовская софтина, то появляется окно "Отправить отчёт об ошибке Биллу?". Всегда интересовало - что ж там отправляется?

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

Так вот,
  • 1. я как-то написал процедуру, которая в случае ошибки пробегалась с помощью классов Reflection по цепочки вложенных друг в друга функций и собирала список что чего вызывало пока не рухнуло. Каково же было моё удивление, когда оказалось что на продакшн-серваке эта процедура просто не стала работать! Трэйс видать отрублен...

  • 2. тогда я добавил в софтину (интранет портал, ASP.Net 2.0), в базовый класс, от которого наследуются все страницы, глобальный список - типа стек. Во всех функциях изменил возвращаемый тип на boolean - флаг успешности или не успешности выполнения функции, а все возвращаемые значения запихнул в параметры передаваемые по ссылке (о, сколько времени занял этот мега-рефакторинг! сразу надо было так делать, да вот только умнеешь всегда после такого как уже наступил на грабли). Соответственно в каждой функции при вызове дочерней проверяется код, который она возвращает, и если он false, то дальше ничего не выполняется, в стек записывается [название класса+название функции+точка на которой всё споткнулось] и идёт выход из функции с возвратом false. В parent-функции ловится этот false, добавляется информация в стек и снова идёт выход с false. И так далее. В самом же низу - везде поставлены try-catch, которые ловят собственно все исключения.
    Вобщем в итоге в трэйс попадает вся цепочка функций, которые вызывались до ошибки. Это здорово помогает при отладке.

  • 3. однако бы хотелось вместе с названиями функций добавлять в трэйс также и список входящих переменных этих функций и их значения. С помощью классов Reflection нельзя выцепить значения переменных - это я уже узнавал, выцепить их список можно - но вдруг тоже не станет работать из-за настроек сервера? Единственным решением, как мне кажется, является добавление первой строкой в каждую функцию вызова специальной процедуры, передавая ей в качестве параметров всё что получает текущая функция, которая бы сохраняла значения входящих переменных на тот случай если трэйс информация понадобится. Однако это опять сложный рефакторинг (хотя если удачно подобрать рекурсивное выражение, то дело на пару часов).

    Вобщем, прежде чем пускаться во все тяжкие, я хотел сначала узнать мож кто как уже организовывал передачу отладочной информации в саппорт?
  • 4 апр 08, 22:49    [5507020]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    905
    Member

    Откуда:
    Сообщений: 159
    почему не сделать обычный вывод в лог файл?
    поменять выходные параметры методов это ты долго думал?
    5 апр 08, 11:25    [5507651]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Николай1
    Member

    Откуда: Москва
    Сообщений: 495
    905
    почему не сделать обычный вывод в лог файл?
    поменять выходные параметры методов это ты долго думал?


    Да уж...
    5 апр 08, 17:14    [5508085]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    Automater
    Во всех функциях изменил возвращаемый тип на boolean - флаг успешности или не успешности выполнения функции,

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

    Automater
    сразу надо было так делать,



    Automater
    Соответственно в каждой функции при вызове дочерней проверяется код, который она возвращает, и если он false,

    Утираю слезы умиления. И небось еще в каждой функции стоит catch, чтобы ловить исключения и преобразовывать их в эту суперпуперофигенную систему образца 1960-го года.

    Automater
    В самом же низу - везде поставлены try-catch, которые ловят собственно все исключения.

    О! Я знал, я знал.

    Automater
    Вобщем, прежде чем пускаться во все тяжкие, я хотел сначала узнать мож кто как уже организовывал передачу отладочной информации в саппорт?

    В общем, это все делается достаточно просто. Тем более в .NET, в котором, если мне не изменяет память, класс Exception заточен как носитель дополнительной информации. Простой пример:

    procedure ReadCfgFile;
    begin
      try
        ReadTextFile ('c:\config.ini');
        ......
      except
        on E: Exception do
         raise AddExceptionHeader (E, 'Ошибка при чтении конфигурационного файла');
      end;
    end;
    
    procedure ReadTextFile (const FileName: string);
    begin
      try
        .....
      except
        on E: Exception do
          raise AddExceptionInfo (E, 'Ошибка при чтении файла', 'Имя файла: %s', [FileName]);
      end;
    end;
    

    В итоге на выходе получается примерно следующее сообщение об ошибке:

    Ошибка при чтении конфигурационного файла
    Ошибка при чтении файла

    Файл не найден (os error code = 2)

    Имя файла: c:\config.ini


    Это сообщение можно показать грамотному пользователю, можно записать в лог, отправить по почте итп. Оно дает вполне адекватную информацию, позволяющую исправить ошибку. Разумеется, не обязательно все пихать именно в текст сообщения - как я говорил, сколь мне помнится, Exception в .NET умеет тащить с собой список пар имя-значение, что позволяет запихнуть туда тексты sql-запросов, значения переменных и все прочее, что захочется знать.
    5 апр 08, 21:34    [5508369]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    KGP
    Member

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


    просто реализовали свой call stack? ok, а остальное, имхо от лукавого.

    softwarer

    Automater
    Вобщем, прежде чем пускаться во все тяжкие, я хотел сначала узнать мож кто как уже организовывал передачу отладочной информации в саппорт?

    В общем, это все делается достаточно просто. Тем более в .NET, в котором, если мне не изменяет память, класс Exception заточен как носитель дополнительной информации.


    заточен не более, чем наличие текстового поля describe (а там уж хоть супер-пупер-свой xml формат используйте).
    7 апр 08, 13:11    [5511871]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    thejediknight
    Member

    Откуда: Moscow
    Сообщений: 32
    Automater
    Когда в Windows падает какая-то майкрософтовская софтина, то появляется окно "Отправить отчёт об ошибке Биллу?". Всегда интересовало - что ж там отправляется?

    StackTrace

    Automater

    Так вот,
  • 1. я как-то написал процедуру, которая в случае ошибки пробегалась с помощью классов Reflection по цепочки вложенных друг в друга функций и собирала список что чего вызывало пока не рухнуло. Каково же было моё удивление, когда оказалось что на продакшн-серваке эта процедура просто не стала работать! Трэйс видать отрублен...

  • Мня бы за такой подход уволили :-)

    Automater

  • 2. тогда я добавил в софтину (интранет портал, ASP.Net 2.0), в базовый класс, от которого наследуются все страницы, глобальный список - типа стек. Во всех функциях изменил возвращаемый тип на boolean - флаг успешности или не успешности выполнения функции, а все возвращаемые значения запихнул в параметры передаваемые по ссылке (о, сколько времени занял этот мега-рефакторинг! сразу надо было так делать, да вот только умнеешь всегда после такого как уже наступил на грабли). Соответственно в каждой функции при вызове дочерней проверяется код, который она возвращает, и если он false, то дальше ничего не выполняется, в стек записывается [название класса+название функции+точка на которой всё споткнулось] и идёт выход из функции с возвратом false. В parent-функции ловится этот false, добавляется информация в стек и снова идёт выход с false. И так далее. В самом же низу - везде поставлены try-catch, которые ловят собственно все исключения.
    Вобщем в итоге в трэйс попадает вся цепочка функций, которые вызывались до ошибки. Это здорово помогает при отладке.
  • Это именно то, чего не нужно было делать, ибо все ужа ДАВНО сделано отлажено и работает!

    Automater

  • 3. однако бы хотелось вместе с названиями функций добавлять в трэйс также и список входящих переменных этих функций и их значения. С помощью классов Reflection нельзя выцепить значения переменных - это я уже узнавал, выцепить их список можно - но вдруг тоже не станет работать из-за настроек сервера? Единственным решением, как мне кажется, является добавление первой строкой в каждую функцию вызова специальной процедуры, передавая ей в качестве параметров всё что получает текущая функция, которая бы сохраняла значения входящих переменных на тот случай если трэйс информация понадобится. Однако это опять сложный рефакторинг (хотя если удачно подобрать рекурсивное выражение, то дело на пару часов).

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

  • Да, microsoft уже такое сделал. 5 лет назад. называеться Exception.
    try
    {
    do_some_work();
    }
    catch (Exception ex)
    {
    SendToSupport(ex.ToString());
    }
    7 апр 08, 13:36    [5512050]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    shelsoft
    Member

    Откуда: Питер FM
    Сообщений: 608
    softwarer
    Уже пятнадцать лет как изобретены исключения

    1) Для обработки ошибок в коде согласен
    2) Для обработки данных ... вот тут уж извольте использование данного механизма не всегда есть хорошо



    ______________________________________________________
    Задолбали вихри яростных атак ...
    7 апр 08, 14:05    [5512279]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    thejediknight
    Member

    Откуда: Moscow
    Сообщений: 32
    shelsoft
    softwarer
    Уже пятнадцать лет как изобретены исключения

    1) Для обработки ошибок в коде согласен
    2) Для обработки данных ... вот тут уж извольте использование данного механизма не всегда есть
    Что имеется ввиду под обработкой данных? Анализ ошибок?
    7 апр 08, 14:14    [5512362]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    shelsoft
    1) Для обработки ошибок в коде согласен
    2) Для обработки данных ... вот тут уж извольте использование данного механизма не всегда есть хорошо

    Соглашусь, но к проблемам автора это явно отношения не имеет.
    7 апр 08, 14:19    [5512401]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    shelsoft
    Member

    Откуда: Питер FM
    Сообщений: 608
    автор
    Что имеется ввиду под обработкой данных? Анализ ошибок?


    Неоднократно сталкивался (в т.ч. не только при внедрении) с такой проблемой когда
    1) Алгоритм обработки данных "верный" - все тестовые примеры "шелкаются" на ура.
    2) Данные, взятые из реальных источников тоже "идеальные" - выборочный контроль отдельной информации из массива данных показывает 100% достоверность
    3) А на выходе, извините "г"

    В таком случае в т.ч. спасают коды завершения. Однако обычно такой добавочный проверочный код маскируется в
    а) #IF MYDEBUG ... #ENDIF
    б) Application.ini (mydebug=enable)


    Есть и другие примеры :)





    ______________________________________________________
    Задолбали вихри яростных атак ...
    7 апр 08, 14:25    [5512455]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    thejediknight
    Member

    Откуда: Moscow
    Сообщений: 32
    shelsoft
    автор
    Что имеется ввиду под обработкой данных? Анализ ошибок?


    Неоднократно сталкивался (в т.ч. не только при внедрении) с такой проблемой когда
    1) Алгоритм обработки данных "верный" - все тестовые примеры "шелкаются" на ура.
    2) Данные, взятые из реальных источников тоже "идеальные" - выборочный контроль отдельной информации из массива данных показывает 100% достоверность
    3) А на выходе, извините "г"

    В таком случае в т.ч. спасают коды завершения. Однако обычно такой добавочный проверочный код маскируется в
    а) #IF MYDEBUG ... #ENDIF
    б) Application.ini (mydebug=enable)

    Есть и другие примеры :)

    Понятно, т.е. нужно обнаружить с какими параметрами ф-я работает не сильно корректно?
    UnitTest не для этого ли нужен?
    7 апр 08, 14:34    [5512523]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    shelsoft
    В таком случае в т.ч. спасают коды завершения.

    Вот тут стопроцентно несогласен. Это ситуация как раз для Exception, в дополнительной информации которого должно идти "какие именно данные левые и чем". Скажем, id обрабатываемой записи и/или значения всех полей из нее.
    7 апр 08, 14:37    [5512557]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    thejediknight
    Member

    Откуда: Moscow
    Сообщений: 32
    softwarer
    shelsoft
    В таком случае в т.ч. спасают коды завершения.

    Вот тут стопроцентно несогласен. Это ситуация как раз для Exception, в дополнительной информации которого должно идти "какие именно данные левые и чем". Скажем, id обрабатываемой записи и/или значения всех полей из нее.


    а если что то типа

    public void go(int id, string userName)
            {
                try
                {
                    .... do some work
                }
                catch (MyCoolExeption ex)
                {
                    ex.addParam("id", id.ToString());
                    ex.addParam("userName", userName);
                    SendToSupport(ex);
                }
            }

    [Serializable]
        public class MyCoolExeption : ApplicationException
        {
            Dictionary<String, String> l = new Dictionary<string, string>();
            public void addParam(String variableName, string valiableValue)
            {
                l.Add(variableName, valiableValue);
            }
        }
    7 апр 08, 14:46    [5512621]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    thejediknight

    Об этом я и говорю. С теми замечаниями, что SendToSupport в данном конкретном коде прилеплен совершенно не на месте, а такой Dictionary давно уже есть и нафиг не надо придумывать его еще раз.
    7 апр 08, 15:04    [5512802]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    shelsoft
    Member

    Откуда: Питер FM
    Сообщений: 608
    softwarer
    Вот тут стопроцентно несогласен ...

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


    ______________________________________________________
    Задолбали вихри яростных атак ...
    7 апр 08, 15:12    [5512884]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    thejediknight
    Member

    Откуда: Moscow
    Сообщений: 32
    softwarer
    thejediknight

    Об этом я и говорю. С теми замечаниями, что SendToSupport в данном конкретном коде прилеплен совершенно не на месте, а такой Dictionary давно уже есть и нафиг не надо придумывать его еще раз.
    Я знаю, что есть, написал для наглядности.
    7 апр 08, 15:15    [5512924]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    thejediknight
    Я знаю, что есть, написал для наглядности.

    Для наглядности стоит как раз делать явные оговорки.... иначе обязательно многие воспримут как прямое руководство к действию :)
    7 апр 08, 15:19    [5512968]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    shelsoft
    Главное чтобы используемое средство реализации позволяло пропустить через такой механизм "верные" данные отобрав "неверные" допустим в пакетном режиме,

    Для этого я поступаю примерно так: в основном цикле "пакетной обработки" коплю вылетающие исключения в список, а дальше, например, выплевываю их как одно суммарное (ну или иначе, по обстановке - например, если речь идет о загрузке плагинов, то логирую список проблематичных, но не торможу дальнейшую работу).
    7 апр 08, 15:23    [5513000]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Automater
    Member

    Откуда:
    Сообщений: 146
    softwarer
    procedure ReadCfgFile;
    begin
      try
        ReadTextFile ('c:\config.ini');
        ......
      except
        on E: Exception do
         raise AddExceptionHeader (E, 'Ошибка при чтении конфигурационного файла');
      end;
    end;
    
    procedure ReadTextFile (const FileName: string);
    begin
      try
        .....
      except
        on E: Exception do
          raise AddExceptionInfo (E, 'Ошибка при чтении файла', 'Имя файла: %s', [FileName]);
      end;
    end;
    

    Трудно тут что-либо возразить опираясь на теорию.

    Но могу оперевшись на практику:
  • Вы при таком подходе забьёте весь код try-catch конструкциями. У меня же они только на нижнем уровне.
  • При вот таком вот коде:
    procedure ReadTextFile (const FileName: string);
    begin
      try
        a = Convert.ToInt32("1");
        b = Convert.ToInt32("2");
        c = Convert.ToInt32("Авотфиг!");
        readFromFile();
      except
        on E: Exception do
          raise AddExceptionInfo (E, 'Ошибка при чтении файла', 'Имя файла: %s', [FileName]);
      end;
    end;
    
    Вы получите ошибку 'Ошибка при чтении файла'. Т.е., в общем случае, трудно установить на какой строчке произошла ошибка. А если каждую строчку "окальцовывать" try-catch'ами, то код будеть выглядеть пугающе.
  • 7 апр 08, 18:18    [5514566]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Automater
    Member

    Откуда:
    Сообщений: 146
    shelsoft
    автор
    Что имеется ввиду под обработкой данных? Анализ ошибок?

    Неоднократно сталкивался (в т.ч. не только при внедрении) с такой проблемой когда
    1) Алгоритм обработки данных "верный" - все тестовые примеры "шелкаются" на ура.
    2) Данные, взятые из реальных источников тоже "идеальные" - выборочный контроль отдельной информации из массива данных показывает 100% достоверность
    3) А на выходе, извините "г"

    В таком случае в т.ч. спасают коды завершения. Однако обычно такой добавочный проверочный код маскируется в
    а) #IF MYDEBUG ... #ENDIF
    б) Application.ini (mydebug=enable)
    Трщи, не уходим от темы. Отладка логики - другое дело. Все "врайт-элэны" пишут... Софтварер пишет что не пишет, но скорее всего лукавит. Как чего по-быстрому надо выяснить наверняка по-быстрому вставляет вывод в файл. Ну да не об этом речь.

    Вобщем, я так понимаю никто список входящих параметров в каждой процедуре на тех же catch'ах в дебаг-лог не выводит? Т.е. все знают только место в котором софтина упала, а почему она упала на этих данных, хотя на тестах работала - это выясняется уже вручную, путём повторения ситуации созданной юзерами и путём вывода "врайт-элэнами" промежуточных данных в тестовый файл?
    7 апр 08, 18:27    [5514627]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Automater
    Member

    Откуда:
    Сообщений: 146
    softwarer
    thejediknight
    Я знаю, что есть, написал для наглядности.

    Для наглядности стоит как раз делать явные оговорки.... иначе обязательно многие воспримут как прямое руководство к действию :)
    Тогда [от меня] ещё одна оговорка - УДОБОЧИТАЕМОСТЬ кода.
    И, как следствие, снижение:
  • стоимости замены специалиста;
  • стоимости поддержки кода.
  • 7 апр 08, 18:30    [5514636]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    Automater
    Трудно тут что-либо возразить опираясь на теорию. Но могу оперевшись на практику:

    Позволю себе замечание "вообще", не имея в виду использовать его как аргумент в конкретном случае: попытка противопоставить теорию практике.. редко является чертой компетентного специалиста. Не стоит двигаться в эту сторону.

    Automater
    Вы при таком подходе забьёте весь код try-catch конструкциями. У меня же они только на нижнем уровне.

    :) А какая у нас конечная цель - написать короткую хорошо работающую программу? Или освободить часть кода от гнета страшных трайкэтчей, попутно раздув ее втрое в размерах и забив жутким нечитаемым кодом проверки статусов?

    Automater
    Вы получите ошибку 'Ошибка при чтении файла'. Т.е., в общем случае, трудно установить на какой строчке произошла ошибка.

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

    Automater
    А если каждую строчку "окальцовывать" try-catch'ами, то код будеть выглядеть пугающе.

    Точнее, так же, как он выглядит окольцованный if-ами.

    Automater
    Все "врайт-элэны" пишут...

    Я бы не стал априори обзывать ламерами всех коллег.

    Automater
    Софтварер пишет что не пишет, но скорее всего лукавит.

    Софтварер за возникновение в коде "врайт-элэнов" увольняет. Вернее, предупреждает, что первый же найденный dbms_output.put_line, System.out.println, MessageBox итп станет последним, и отмазки типа "да я сейчас уберу, в релизе не будет" не прокатят. Желающих проверить это на практике он пока не встречал.

    Как чего по-быстрому надо выяснить наверняка по-быстрому вставляет вывод в файл. Ну да не об этом речь.

    Automater
    Вобщем, я так понимаю никто список входящих параметров в каждой процедуре на тех же catch'ах в дебаг-лог не выводит?

    В общем ты еще и читать не умеешь.

    Automater
    Тогда [от меня] ещё одна оговорка - УДОБОЧИТАЕМОСТЬ кода.

    Да, код с обработкой исключений действительно куда удобочитаемее. Но это не главное его достоинство, всего лишь третье по значимости. Первое - он куда надежнее, второе - легче в модификации.
    7 апр 08, 18:53    [5514742]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Automater
    Member

    Откуда:
    Сообщений: 146
    softwarer
    редко является чертой компетентного специалиста.
    По моему глубокому убеждению, программист должен быть "толковым", а не заумным. Это означает что он как не должен почитать Страуструпа как священную корову.
    Стремление писать простой код я нахожу уместным в бизнесе.
    softwarer
    Чтобы установить строчку, я использую стектрейс
    А у меня удалённый сервак где любой трэйс запрещён.
    softwarer
    Точнее, так же, как он выглядит окольцованный if-ами.
    Не хочу приводить сравнительные примеры - лень. У меня - плюс одна строчка, у него - плюс пять. Не пойму о чём разговор.
    softwarer
    Automater
    Все "врайт-элэны" пишут...

    Я бы не стал априори обзывать ламерами всех коллег.
    Я бы не стал скрывать очевидное.
    softwarer
    Как чего по-быстрому надо выяснить наверняка по-быстрому вставляет вывод в файл.
    Чудно: вывод в сообщение и вывод в файл - разные методы отладки.
    softwarer
    Первое - он куда надежнее, второе - легче в модификации.
    Добавление if'а совершенно не уменьшает надёжность. Все критические ошибки всё равно ловятся catch'ами.
    При модификации легче изменить то что написано рядом с потенциально опасной строчкой, а не то что находится catch'е на несколько экранов ниже.
    7 апр 08, 20:16    [5514983]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Petro123
    Member

    Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
    Сообщений: 38640
    Automater
    часто пишу 2 варианта:

    1 вариант
      try  a = Convert.ToInt32("1");             except    on E: Exception do      raise 'xvdcd' + fvfv;  end;
      try  b = Convert.ToInt32("2");             except    on E: Exception do      raise 'xvdcd' + fvfv;  end;
      try  c = Convert.ToInt32("Авотфиг!");  except    on E: Exception do      raise 'xvdcd' + fvfv;  end;
    2 вариант - в соответствии с ООП оборачиваем Convert.ToInt32("1"); более умной процедурой, которая наверх возвращает райзе. Куча глупых строк никому ненужна.

    ______________________________________________
    Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
    8 апр 08, 09:49    [5516001]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    thejediknight
    Member

    Откуда: Moscow
    Сообщений: 32
    using System;
    using System.Collections;
    namespace Example
    {
        public class Example
        {
            public static void Main()
            {
                try
                {
                    new Example().run(102, 104, 109);
                }
                catch (Exception ex)
                {
                    Console.WriteLine(ex.ToString());
                    Console.WriteLine("---------------");
                    foreach (DictionaryEntry d in ex.Data)
                    {
                        Console.WriteLine(String.Format("{0}={1}", d.Key, d.Value));
                    }
                }
                Console.ReadKey();
            }
            public void run(int z, int y, int x)
            {
                try
                {
                    do_usefull_work(0, "zero");
                    do_usefull_work(1, "one");
                    do_usefull_work(2, "two");
                    do_usefull_work(3, "three");
                }
                catch (Exception ex)
                {
                    ex.Data.Add("z", z);
                    ex.Data.Add("y", y);
                    ex.Data.Add("x", z);
                    throw;
                }
            }
            int do_usefull_work(int a, string b)
            {
                try
                {
                    if (a == 2) throw new Exception("so bad :-)");
                }
                catch (Exception ex)
                {
                    ex.Data.Add("a", a);
                    ex.Data.Add("b", b);
                    throw;
                }
                return (2 + 2);
            }
        }
    }

    OUTPUT:

    System.Exception: so bad :-)
       at Example.Example.do_usefull_work(Int32 a, String b) in C:\projects\Composite\Composite\Example.cs:line 51
       at Example.Example.run(Int32 z, Int32 y, Int32 x) in C:\projects\Composite\Composite\Example.cs:line 38
       at Example.Example.Main() in C:\projects\Composite\Composite\Example.cs:line
    11
    ---------------
    a=2
    b=two
    z=102
    y=104
    x=102

    any questions?
    8 апр 08, 11:27    [5516826]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Диез
    Member

    Откуда: Столица Попозже.
    Сообщений: 894
    Automater

  • При вот таком вот коде:
    procedure ReadTextFile (const FileName: string);
    begin
      try
        a = Convert.ToInt32("1");
        b = Convert.ToInt32("2");
        c = Convert.ToInt32("Авотфиг!");
        readFromFile();
      except
        on E: Exception do
          raise AddExceptionInfo (E, 'Ошибка при чтении файла', 'Имя файла: %s', [FileName]);
      end;
    end;
    
    Вы получите ошибку 'Ошибка при чтении файла'. Т.е., в общем случае, трудно установить на какой строчке произошла ошибка. А если каждую строчку "окальцовывать" try-catch'ами, то код будеть выглядеть пугающе.


  • Пример странный, никакого смысла такой код не несет. Ну да ладно... :)

    Convert.ToInt32() и File.ReadAllText() (к примеру) будут выбрасывать совершенно разные типы исключений. Вот их и ловите по очереди, а в конце уже ловите общий Exception.
    8 апр 08, 11:45    [5517024]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Petro123
    Member

    Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
    Сообщений: 38640
    Диез

    будут выбрасывать совершенно разные типы исключений. Вот их и ловите

    +1
    да, это 3-ий вариант.
    Раньше были go to всякие
    Есть библиотеки, которые не только стек отправляют, но и скриншот и т.д.
    8 апр 08, 12:18    [5517333]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Automater
    Member

    Откуда:
    Сообщений: 146
    Диез
    Automater

  • При вот таком вот коде:
    Вы получите ошибку 'Ошибка при чтении файла'. Т.е., в общем случае, трудно установить на какой строчке произошла ошибка. А если каждую строчку "окальцовывать" try-catch'ами, то код будеть выглядеть пугающе.


  • Пример странный, никакого смысла такой код не несет. Ну да ладно... :)

    Convert.ToInt32() и File.ReadAllText() (к примеру) будут выбрасывать совершенно разные типы исключений. Вот их и ловите по очереди, а в конце уже ловите общий Exception.
    Мой шеф, любитель как раз таки этого подхода, именно этим и занимается. Прелесно смотреть на его список "потенциальных ошибок", который, естественно, не включает в себя весь спектр возможных. Конечно в итоге он ловит "общую" ошибку, если остальные не подошли, но смшно смотреть на то как человек мучается. Потом он ещё начинает изобретать свои классы исключений. Ведь надо же "вывалиться" из программы аварийным способом не только когда строчка не конвертится в число, а когда и процедура обращающаяся к базе вернула пустое множество, т.е. в случае логической ошибки. Ох, как жешь Билли заставляет людей раскорячиваться!

    Кроме того это не решает проблемы удобочитаемости кода. Обработки всевозможных ситуаций находятся на несколько экранов ниже, а не рядом с потенциально опасными строками.
    8 апр 08, 23:40    [5521667]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Petro123
    Member

    Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
    Сообщений: 38640
    Automater

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

    :) у кого какой бизнес. У некоторых он вываливается когда "база вернула пустое множество"
    :)
    9 апр 08, 09:29    [5522198]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Диез
    Member

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


    Ну помучается, зато результат лучше будет. :) .

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

    Automater

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


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

    Automater

    Ох, как жешь Билли заставляет людей раскорячиваться!

    Похоже, вы на Java не писали никогда. Вот где заставляют, так заставляют
    9 апр 08, 11:38    [5523232]     Ответить | Цитировать Сообщить модератору
     Извините что опять поднимаю тему.  [new]
    Automater
    Member

    Откуда:
    Сообщений: 146
    Диез

    Ну и что? Вы "оборачиваете" внешние исключения плюс логические ошибки - в коды возврата; он - их же оборачивает в бизнес-исключения, которые точно так же обрабатывает вызывающий код (совершенно необязательно вываливаться из программы при этом).
    В чем разница-то?
    В том что у меня код короче! Вопрос в стоимости поддержки софта, т.е. о количестве времени требуемом новому (или старому, но забывшему) программеру на то чтобы разобраться с логикой процедуры. Если обработка события стоит в 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 апр 08, 21:53    [5582290]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    Automater
    Вопрос в стоимости поддержки софта,

    Какой же ты смешной....

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

    Читать ты за эти две недели так и не научился.

    P.S. Нехорошо, конечно, посвящать весь пост обсуждению личности и только личности, но других комментариев просто нет. Видать, это карма. Причем того, кому потом достанется возиться с этим, когдла ты свалишь.
    22 апр 08, 22:52    [5582403]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    Диез
    Member

    Откуда: Столица Попозже.
    Сообщений: 894
    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 апр 08, 09:38    [5583124]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    KGP
    Member

    Откуда: Москва
    Сообщений: 4554
    Диез

    Существует хорошая практика - делать код метода высотой не более полутора экранов.


    имхо это применялось для 'обзорности кода', когда студии имеют 'сворачивание кода' это менее актуально (например регионы, скобки ... в ms vs)
    23 апр 08, 09:44    [5583156]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    Диез
    Member

    Откуда: Столица Попозже.
    Сообщений: 894
    KGP
    Диез

    Существует хорошая практика - делать код метода высотой не более полутора экранов.


    имхо это применялось для 'обзорности кода', когда студии имеют 'сворачивание кода' это менее актуально (например регионы, скобки ... в ms vs)


    Code folding - штука удобная, не спорю. Но, думаю, дело тут не только в обзорности, но и в структурировании кода.

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

    - самодокументируемость кода, при наличии адекватных имен :)
    - удобство отладки
    - при возникновении эксепшена пишется Stack Trace в лог, а потом мы однозначно устанавливаем место возникновения ошибки по именам методов


    То есть идея такова, что если тело метода больше полутора страниц, то стоит задуматься о рефакторинге.
    23 апр 08, 10:44    [5583545]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    Диез
    Code folding - штука удобная, не спорю.

    Я, кстати, поспорю. Эта штука удобна имхо в двух случаях:

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

    2. Плохой, нечитаемый язык, который не отделяет декларации методов от их реализации, а следовательно не дает возможность увидеть интерфейс класса, забивая экран текстом методов. Ну а с code folding-ом видно хоть как-то, просто дополнительный мусор на экране.

    Имхо в обоих случаях нужно исправлять причину, а не подставлять костыль code folding-а. Что же до нормального кода - не припомню, чтобы возникало желание пользоваться сверткой.

    Диез
    То есть идея такова, что если тело метода больше полутора страниц, то стоит задуматься о рефакторинге.

    Только стоит помнить, что это именно "идея", а не безусловное правило.
    23 апр 08, 11:01    [5583658]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    KGP
    Member

    Откуда: Москва
    Сообщений: 4554
    Диез

    Логично будет вынести методы работы с БД и с вебсервисом в отдельные классы, тогда тело моего метода будет состоять просто из вызова трех внешних методов и обработки ошибок.


    1. а если и это будет 'более полутора экранов'?
    2. а если завтра ваш экран будет 22', а не 17'?
    3. как связано 'в отдельные классы', 'трех внешних методов' с 'более полутора экранов', почему не просто 3 отдельные функции того же класса?

    ps: мне не понятна роль аргумента 'более полутора экранов'
    23 апр 08, 11:23    [5583831]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    Petro123
    Member

    Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
    Сообщений: 38640
    KGP

    ps: мне не понятна роль аргумента 'более полутора экранов'

    на камне написано: "Направо пойдешь - коня потеряешь. ".
    Нет, найдётся человек который неповерит :))
    23 апр 08, 12:01    [5584198]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    Диез
    Member

    Откуда: Столица Попозже.
    Сообщений: 894
    KGP
    Диез

    Логично будет вынести методы работы с БД и с вебсервисом в отдельные классы, тогда тело моего метода будет состоять просто из вызова трех внешних методов и обработки ошибок.


    1. а если и это будет 'более полутора экранов'?
    2. а если завтра ваш экран будет 22', а не 17'?
    3. как связано 'в отдельные классы', 'трех внешних методов' с 'более полутора экранов', почему не просто 3 отдельные функции того же класса?

    ps: мне не понятна роль аргумента 'более полутора экранов'


    1, 2. Естественно, полтора - это величина условная. Просто большая длина обычно требует более одного движения для полного обзора :)

    3. Никто не мешает сделать методы того же класса, но часто удобнее и логичнее разнести код на уровни, т.е. в отдельные классы (а то и в отдельные библиотеки).

    Вообще, все это есть у Фаулера :)
    23 апр 08, 12:11    [5584290]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    Диез
    Member

    Откуда: Столица Попозже.
    Сообщений: 894
    Petro123
    KGP

    ps: мне не понятна роль аргумента 'более полутора экранов'

    на камне написано: "Направо пойдешь - коня потеряешь. ".
    Нет, найдётся человек который неповерит :))

    23 апр 08, 12:14    [5584309]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    KGP
    2. а если завтра ваш экран будет 22', а не 17'?

    Насколько мне известно, споры "подпрограмма должна быть не больше сорока строк или все же можно до пятидесяти" шли еще в шестидесятые года прошлого века. Думаю, что и в шестидесятом веке будут ломать копья об аналогичном в целом вопросе
    23 апр 08, 12:34    [5584491]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    KGP
    Member

    Откуда: Москва
    Сообщений: 4554
    softwarer

    Насколько мне известно, споры "подпрограмма должна быть не больше сорока строк или все же можно до пятидесяти" шли еще в шестидесятые года прошлого века. Думаю, что и в шестидесятом веке будут ломать копья об аналогичном в целом вопросе


    если нет ООП-предпосылки к разбиению, а лишь проблема в не_возможности_одним_вглядом_охватить_нечто, то почему и не ограничится применением Code folding?
    23 апр 08, 12:52    [5584679]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    egorych
    Member

    Откуда: и зачем;
    Сообщений: 4809
    что есть "ООП-предпосылка" и чем она важнее, нежели желание видеть весь код метода без всяких разных свёртываний?
    23 апр 08, 13:10    [5584860]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    Диез
    Member

    Откуда: Столица Попозже.
    Сообщений: 894
    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 апр 08, 13:11    [5584868]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    Диез
    Но в современных IDE эта разница нивелируется.

    Бесспорно, нивелируется. Тем не менее я вижу разницу между "полезной фичой IDE, реально делающей жизнь лучше" и "костылем, который IDE подставляет там, где кто-то схалтурил". По мне code folding куда ближе ко второму варианту. А такие фичи мне не очень нравятся, так как их наличие провоцирует дальнейшее нарастание кривых решений: мол, сделаем плохо, а IDE потом будет нивелировать.

    Я вовсе не призываю программировать в notepad-е, но полагаю, что уход от него должен осуществляться там, где оно стоит и так, чтобы стоило. Простейшим примером назову visual diff: делая check in / check out, я заинтересован в том числе компактно и четко увидеть "что поменялось в интерфейсе класса", и code folding мне здесь не сказать, что поможет.
    23 апр 08, 15:44    [5586054]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    Диез
    Member

    Откуда: Столица Попозже.
    Сообщений: 894
    softwarer

    Я вовсе не призываю программировать в notepad-е, но полагаю, что уход от него должен осуществляться там, где оно стоит и так, чтобы стоило. Простейшим примером назову visual diff: делая check in / check out, я заинтересован в том числе компактно и четко увидеть "что поменялось в интерфейсе класса", и code folding мне здесь не сказать, что поможет.

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

    В приложении небольшой пример, который покажет совсем не то, что вы ожидаете. А если методов штук тридцать, да еще меняются модификаторы видимости?..

    Так что, ИМХО, в вашем примере с diff, отделение интерфейса от реализации - скорее недостаток языка, позволяющий незаметно выстрелить себе в ногу.
    24 апр 08, 12:36    [5590336]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Диез
    Member

    Откуда: Столица Попозже.
    Сообщений: 894


    К сообщению приложен файл. Размер - 0Kb
    24 апр 08, 12:37    [5590337]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67169
    Блог
    Диез
    Да, в простых случаях такой подход сработает.

    Да и в остальных тоже недурен.

    Диез
    Но в общем случае diff сравнивает текст внутри файла, но отнюдь не языковые элементы.

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

    Диез
    В приложении небольшой пример, который покажет совсем не то, что вы ожидаете.

    Любопытно, откуда Вы знаете, чего я ожидаю? :)

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

    Диез
    А если методов штук тридцать, да еще меняются модификаторы видимости?..

    И что страшного? Хоть триста.

    Диез
    Так что, ИМХО, в вашем примере с diff, отделение интерфейса от реализации - скорее недостаток языка, позволяющий незаметно выстрелить себе в ногу.

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

    Фразу "отделение интерфейса от реализации - скорее недостаток", как Вы понимаете, есть желание вырезать, повесить на стенку и цитировать :) На самом деле, я бы сказал, недостатком языка (дельфы) является как раз недостаточное их отделение, в частности, потребность описывать private часть публичного класса в interface секции модуля.
    24 апр 08, 15:56    [5591946]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    Николай1
    Member

    Откуда: Москва
    Сообщений: 495
    [quot Диез
    А вот что, имхо, вам предстоит в ближйшем будущем:

    - сначала вам перестанет хватать Boolean на все случаи, вы переделаете коды возврата на Shortint
    - потом захотите возвращать еще и некую текстовую информацию, придется возвращать Record.
    - с увеличением уровней вложенности методов захотите разработать универсальный обработчик цепочки вызовов.
    - с удивлением обнаружите, что повторили модель исключений...

    Повторюсь, это имхо, просто сам через это прошел когда-то.

    [/quot]

    Boolean сразу не хватает на все случаи жизни. За код возврата BOOLEAN сразу бы руки отрубал.
    У меня вот нету эксепшенов (точне есть, но такие, скромные), так что приходится строку вверх гнать. По пути она обрастает описанием с каждой кокретной точки и, в итоге, видно, путь на котором "сломалось". Удобно. А проверять надо _все_ ибо сломаться может в любом месте, даже там, где, казалось бы, ничего не грозило...
    1 май 08, 21:10    [5616820]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    Диез
    Member

    Откуда: Столица Попозже.
    Сообщений: 894
    Николай1



    А на чём пишете? Чем не устраивают исключения?
    Кстати, что значит "скромные" эксепшены?
    3 май 08, 15:52    [5619386]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    Lepsik
    Member

    Откуда: glubinka
    Сообщений: 4256
    Диез
    1, 2. Естественно, полтора - это величина условная. Просто большая длина обычно требует более одного движения для полного обзора :)

    3. Никто не мешает сделать методы того же класса, но часто удобнее и логичнее разнести код на уровни, т.е. в отдельные классы (а то и в отдельные библиотеки).

    Вообще, все это есть у Фаулера :)


    это просто у вас программы маленькие. :)

    в больших компаниях Microsoft/IBM/SONY, .... таких правил нет.
    У нас есть методы с телом в сотню экранов.
    А файл с методом тела процесса больше мегобайта.
    6 май 08, 17:52    [5632700]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    Диез
    Member

    Откуда: Столица Попозже.
    Сообщений: 894
    Lepsik
    Диез
    1, 2. Естественно, полтора - это величина условная. Просто большая длина обычно требует более одного движения для полного обзора :)

    3. Никто не мешает сделать методы того же класса, но часто удобнее и логичнее разнести код на уровни, т.е. в отдельные классы (а то и в отдельные библиотеки).

    Вообще, все это есть у Фаулера :)


    это просто у вас программы маленькие. :)

    в больших компаниях Microsoft/IBM/SONY, .... таких правил нет.
    У нас есть методы с телом в сотню экранов.
    А файл с методом тела процесса больше мегобайта.


    Ну, вообще-то это не абсолютное правило, а рекомендация (на мой взгляд, вполне разумная).

    С другой стороны, код пишут не крупные компании, а конкретные люди в этих компаниях. В том числе всякие "индусы", которым, по легендам, платят за количество строк кода :))

    Кстати, можете привести примеры от Microsoft/Sony/IBM ? А то вы так уверенно утверждаете, как будто сами работаете во всех трех... ;)
    7 май 08, 11:37    [5635204]     Ответить | Цитировать Сообщить модератору
     Re: Извините что опять поднимаю тему.  [new]
    stoune
    Member

    Откуда:
    Сообщений: 1
    Диез


    Ну, вообще-то это не абсолютное правило, а рекомендация (на мой взгляд, вполне разумная).

    С другой стороны, код пишут не крупные компании, а конкретные люди в этих компаниях. В том числе всякие "индусы", которым, по легендам, платят за количество строк кода :))

    Кстати, можете привести примеры от Microsoft/Sony/IBM ? А то вы так уверенно утверждаете, как будто сами работаете во всех трех... ;)



    Всё очень просто. Психологи давно выяснили что в кратковременной (оперативной памяти) может держатся около 4-5 вещей одновременно. Видя весь код на одном экране легче представить себе всю картину. Когда нужна прокрутка вероятность упустить что-то важное существенно увеличивается. Поэтому при code review своих колег, а они при проверке моего требуем без оправданной необходимости(большие switch, генератор кода etc...) укладываться в те пресловутые 1-2 экрана. Как по мне это азы и слышать возражения от профессиональных программистов мне как-то не по себе.

    P. S. Вообще рекомендую курить Совершенный код Маккoннелл С. . Там очень большая коллекция здравых рецептов как облегчить себе и колегам жизнь.
    10 май 08, 15:45    [5646413]     Ответить | Цитировать Сообщить модератору
     Re: Отправка отладочной информации саппорту?  [new]
    Q
    Guest
    http://blogs.technet.com/not-a-kernel-guy/archive/2008/05/10/3053255.aspx
    Алексей Пахунов (c)
    12 май 08, 10:37    [5649269]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: 1 2 3      [все]
    Все форумы / Разработка информационных систем Ответить