Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Разработка информационных систем Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Отправка отладочной информации саппорту?  [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
    Сообщений: 67154
    Блог
    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
    Сообщений: 67154
    Блог
    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
    Сообщений: 67154
    Блог
    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
    Сообщений: 67154
    Блог
    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
    Сообщений: 67154
    Блог
    thejediknight
    Я знаю, что есть, написал для наглядности.

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

    Откуда: 127.0.0.1
    Сообщений: 67154
    Блог
    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
    Сообщений: 67154
    Блог
    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]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
    Все форумы / Разработка информационных систем Ответить