Home/ Questions/Q 123181
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T04:14:45+00:00

Surprisingly I was only able to find one previous question on SO about this

  • 0

Surprisingly I was only able to find one previous question on SO about this subject, and I’d just like to get the community ‘Vote of Confidence’ (or not!) on my approach.

The way I see it is thus:

  • use Debug.Assert to state things you EXPECT would be true. This would be used when we are in complete control over our environment, for example in a method to verify some pre and post-conditions.
  • use Exceptions when exceptional circumstances arise. Dealing with external resources, i.e. files, databases, networks etc is a no-brainer. But…

It gets a little murky in the following scenario. Please note that this is a CONTRIVED EXAMPLE for illustration only!

Say we have class MyClass, which has a public property MyMode and a method GetSomeValueForCurrentMode(). Consider MyClass as one intended to be shipped (release built) in a library for use by other developers.

We expect MyMode to be updated by external users of this class. Now, GetSomeValueForCurrentMode() has the following logic:

switch(MyMode) { case Mode.ModeA: return val1; case Mode.ModeB: return val2; default: //Uh-uh this should never happen  }

What I’m getting at here is that the user of MyClass has left it in an invalid state. So what should we do?

In the default, should we Debug.Assert or throw new InvalidOperationException (or other) ?

There is one mantra that says we should not trust users of our classes. If we choose Debug.Assert and built MyClass as a release build (thereby removing the Debug Asserts) the user of the class wouldn’t get helpful information that they had left it in an invalid state. But it’s sort of contrary to the other mantra which says only throw exceptions when things completely out of your control happen.

I find I go round in circles with this – one of those programming debates that don’t seem to have a definitive ‘correct’ answer. So let’s put it to the vote!

Edit: I noticed this response in a related SO question (Design by contract using assertions or exceptions?):

The rule of thumb is that you should use assertions when you are trying to catch your own errors, and exceptions when trying to catch other people’s errors. In other words, you should use exceptions to check the preconditions for the public API functions, and whenever you get any data that are external to your system. You should use asserts for the functions or data that are internal to your system.

To me, this makes sense, and can be coupled with the ‘Assert then throw’ technique outlined below.

Thoughts welcome!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. I agree with most people here and follow Design-by-Contract. You should try and differentiate very clearly between requirements in deployed code (Contracts) and figuring out expected state during design (Debugging Assertions).

    You should ALWAYS throw contract assertions as exceptions (as they should always be exceptional). There are mechanisms built in to most frameworks for catching debug assertions. But at runtime you should always throw an exception.

    I use a custom library to help with this (in C#/VB.NET). I recently put up it up on Codeplex (http://www.contractdriven.com/) if you’re interested in how this works in practice.

    A side benefit of this is that as you start using DbC more regularly, you seldom need to use debugging assertions as there are already explicit guarantees written in to your code, so it’s actually difficult to get in to an invalid state.

    So the question in your original post… ‘What I’m getting at here is that the user of MyClass has left it in an invalid state. So what should we do?’…should never arise.

    You may never need to debug anything again! 😉

    • 0