Как я могу безопасно Debug.Assert в ASP.NET? - PullRequest
Новая
       18

Как я могу безопасно Debug.Assert в ASP.NET?

3 голосов
/ 08 апреля 2010

Утверждения не могут быть пойманы.Это хорошо, потому что некоторые ошибки, которые я не хочу включать в try / catch, по крайней мере, не на сервере разработки.Но утверждения кажутся ужасно опасными.Если они попадают в производство, он может повесить сервер ASP.NET с помощью msgbox. 

//Don't want this on prod even if debug=true is in the web.config
#if DEBUG
    //A future client programmer can wrap this in a try{}catch{}
    if (!EverythingIsOkay)
        throw new InvalidOperationException("Dagnabbit, programming error");

    //This stops the but has less information that an
    // Exception and hangs the server if this accidentally 
    // runs on production
    System.Diagnostics.Debug.Assert(!EverythingIsOkay);
#endif

Есть ли лучший способ сообщить разработчику о нарушении неприкосновенного состояния, не рискуя повесить IIS?

ОБНОВЛЕНИЕ : после прочтения первых ответов, я полагаю, что ответ зависит от надежного способа определения, когда код выполняется в среде разработки и когда он находится на рабочем сервере, или выяснения, какгенерировать исключение, которое не может быть перехвачено и проигнорировано.

Ответы [ 4 ]

2 голосов
/ 08 апреля 2010

Не вижу проблемы. Сделай как первый и брось исключение. Тогда сервер не зависнет. Также вы никогда не должны использовать debug.Assert в производстве (как вы упомянули).

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

1 голос
/ 08 апреля 2010

Я лично создал класс под названием «Защита» с двумя методами: «Утвердить» и «Сбой». Assert работает подобно xUnit «assert» в том, что оно принимает логическое условие и сообщение и выдает исключение с сообщением, если условие ложно. Fail бросает исключение сразу.

Это супер-просто и спасло мои туч много-много раз. Это ASP.NET дружественный и умирает быстро и быстро. Если вы обеспокоены тем, что эти ошибки возникают в реальном мире, вы можете изменить метод Assert, чтобы он вместо этого записывал в журнал, используя директивы предварительной обработки (#if DEBUG ... #endif), но в своей работе я бы предпочел увидеть серьезные ошибки в реальном мире чем скрыть их и не знать, что случилось.

1 голос
/ 08 апреля 2010

Вместо того, чтобы использовать Диагностику Debug.Assert, не могли бы вы использовать инструмент ведения журнала (например, log4net) или насос сообщений в реальном времени (сокет TCP или база данных) для регистрации результатов «настраиваемого» Assert?Вы хотите прекратить выполнение при сбое Assert?

0 голосов
/ 14 января 2016

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

Обнаружение, если вы работаете, зависит от вас, вы можете использовать соглашения об именах для серверов и проверить Environment.MachineName (если это разрешено вашей сети), или использовать appSetting в вашем web.config. *

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

Чтобы убить вашу страницу asp.net, вы можете попробовать Response.Radirect на страницу ошибок программиста или сделать это вручную 

  Response.Clear()
  Response.Write("Fool! You made a dagnabbit programming error!");
  Response.End();

Это должно убить вашу страницу, если кто-то не использует антипаттерн try / catch (Exception ex).

...