开发者

How do I safely Debug.Assert in ASP.NET?

开发者 https://www.devze.com 2022-12-25 19:30 出处:网络
Asserts can\'t be caught.This is good because some errors I don\'t want to be wrapped in try/catch, at least not on the development server.But Asserts seem awefully dangerous.If they get onto producti

Asserts can't be caught. This is good because some errors I don't want to be wrapped in try/catch, at least not on the development server. But Asserts seem awefully dangerous. If they get onto production, it can hang the ASP.NET server with a 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")开发者_JS百科;

    //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

Is there better way to communicate an violation of a inviolable condition to a developer without risking hanging IIS?

UPDATE: After reading the first replies, I guess the answer hinges on a foolproof way to detect when code is running in a development environment and when it is on a production server, or figuring out how to throw an exception that can't be caught and ignored.


I personally created a class called "Defense" with two methods, "Assert" and "Fail." Assert works similarly to xUnit "assert" in that it takes a boolean condition and a message and throws an exception with the message if the condition is false. Fail throws the exception right away.

It's super-simple and has saved my tuches many, many times. It's ASP.NET friendly and dies hard and fast. If you're concerned about these errors being thrown in the real world you can modify the Assert method so it logs instead using preprocessing directives (#if DEBUG ... #endif), but in my line of work I'd rather see hard errors in the real world than hide them and not know what happened.


Don't really see the problem. Do like the first one and throw an exception. Then the server wont hang. Also you should never use debug.Assert in production(as you mentioned).

Throwing an exception will stop the execution aswell and you will be able to catch it. Just make sure that you log the exception and you will be fine with debugging.


Rather than using the Diagnostics Debug.Assert, could you use a logging tool (i.e. log4net) or a realtime message pump (TCP socket or database) to log the results of a "custom" Assert? Are you wanting to stop executing when the Assert fails?


Well, you can't make everything foolproof, fools are much too ingenious ;)

Detecting if you are in production is up to you, you can exploit naming conventions for servers and check Environment.MachineName (if your web is is allowed to do so), or use an appSetting in your web.config.

I am not sure if Debug.Assert() would hang the Server, did you try that on your development server? MSDN says that Assert shows a message box only when in user interface mode - without specifying what happens otherwise.

To kill your asp.net page, you could try a Response.Redirect to a Programmer's Error Page, or do it manually by

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

This should kill your page, unless somebody uses the try/catch(Exception ex) antipattern.

0

精彩评论

暂无评论...
验证码 换一张
取 消