Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The main reason I don't like Debug.Assert is the fact that these assertions are disabled in Release. I know that there's a performance reason for that, but at least in my situation I believe the gains would outweigh the cost. (By the way, I'm guessing this is the situation in most cases). And yes, I know that you can use Trace.Assert instead. But even though that would work, I find the name Trace distracting, since I don't see this as tracing.

The other reason to create my own class is laziness I guess, since I could write methods for the most usual cases like Assert.IsNotNull, Assert.Equals and so forth.

The second part of my question has to do with using Environment.FailFast in this class. Would that be a good idea? I do like the ideas put forth in this document. That's pretty much where I got the idea from.

One last point. Does creating a design like this imply having an untestable code path, as described in this answer by Eric Lippert on a different (but related) question?

share|improve this question
2  
If you need your assertions in release builds, you're doing something wrong. "Real" assertions can only fail if the program is flawed. –  delnan Mar 19 '12 at 15:22
1  
I've never understood this argument about assertions. Does that mean that a flawed program can never make it to production? It shouldn't, but can you be sure that will never happen? –  Mike Mar 19 '12 at 15:27
2  
It means you don't turn debugging off for a program that needs debugging ;) Pragmatically, the issue is decided by the fact that they are commonly removed in release builds. From an idealistic POV, it's slightly harder to justify, yes. But still: Assertions are a tool to detect impossible states as early as possible - a debugging help. They are not a way of detecting errors and for failing reliably, you should use exceptions or whatever for that. –  delnan Mar 19 '12 at 15:37
    
Maybe you should consider using logging as well as asserts - this has the advantage that when you suspect a bug, you can just turn up the log level and watch. –  Michael K Mar 19 '12 at 18:55

3 Answers 3

up vote 1 down vote accepted

Yes, create your own Assert if it fulfils your requirements

Some companies have no 'release' build - the single build that they use has compiler optimisations disabled, ASSERT-like macros still in place and a ton of logging. Being able to dynamically enable/configure ASSERT behaviour at runtime is helpful here. You want ASSERT-like behaviour in that if something doesn't pass a test, do something about it rather than let the program continue but being able to toggle abort, logging, timing, stat collection and throw-an-exception behaviour at runtime is hugely useful, especially if you have large server applications with lots of clients and which can have long uptimes.

System.Diagnostics.Assert certain does the abort behaviour and System.Diagostics.Trace does the logging, but it may well suit your purposes to have some blend thereof which was configurable through .config or Registry means and gave you access to whatever you need to ensure that the quality of your software meets your requirements.

I can't predict what would be useful to you, but as a starting point:

  • Is a failing conditional fatal, a warning or trace.
  • Should the code abort, throw, log, email or SMS the issue.
  • Whether to keep stats on the above items.
  • Whether allow live configuration of all these (useful for server processes).
share|improve this answer

If Trace has all the functionality you need and you really can't bare the name "Trace" can you just inherit from it to mask the name?

share|improve this answer
    
Well, you're comment is very pertinent in that the question I should be asking myself is if Trace has all the functionality I want. I guess the answer is No. –  Mike Mar 19 '12 at 15:12

The main reason I don't like Debug.Assert is the fact that these assertions are disabled in Release

What you're looking for are Code Contracts; a library from Microsoft that lets you make assertions that shouldn't be violated (IE, null arguments or a bank account variable going lower than zero just before a calculation of interest).

They offer several ways to express your constraints and a static checker to warn you about pitfalls in your codebase without ever running any code.

Look into "Design by contract" for non-.NET information on this.

share|improve this answer
    
I had heard of code contracts before but never paid much attention to it. Now I've spent the last hour reading about it and it sounds interesting. Not sure yet if that's exactly what I need, but thanks for pointing me in that direction. –  Mike Mar 19 '12 at 18:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.