a = b;
assert(a == b);

a = b;
assert(a == b);
if (a != b) { return error; }

Debug.Assert(null != table, "null != table");
if (null == table)
    throw new ArgumentNullException("table");

M>>Агресивное vs. защитное (agressive vs. defensive) программирование. В агрессивном вызывающая функция должна заботиться о правильности передаваемых параметров, а вызываемая — вылетать нафиг при первом же неудобном случае

M>>Иначе никаких if-ов и try-catch-ев не напасешься

_FR>Хм: в дотнете прекрасно напасаются

3.13 Не программируйте в "защитном" стиле

"Защищающаяся" программа — это такая программа, в которой программист не доверяет входящим данным в той части системы, которую он программирует. В общем случае программист не должен проверять данные, передаваемые в функции, на правильность. Большая часть кода в системе должна быть написана с преположением, что входящие в функцию данные корректны. Только маленькая часть кода должна работать над проверкой данных. Это обычно происходит, когда данные "входят" в систему в первый раз. Как только эти данные вошли в систему, они отныне должны считаться правильными

3.13 Do not program "defensively"

A defensive program is one where the programmer does not "trust" the input data to the part of the system they are programming. In general one should not test input data to functions for correctness. Most of the code in the system should be written with the assumption that the input data to the function in question is correct. Only a small part of the code should actually perform any checking of the data. This is usually done when data "enters" the system for the first time, once data has been checked as it enters the system it should thereafter be assumed correct.

>void my_assert(bool cond, const char* sz_cond, const char* func, const char* file, long line)
>{
>    if (IsDebuggerPresent())
>    {
>        __asm int 3
>    }
>    else
>    {
>        DebugWriteStack(sz_cond, func, file, line);
>        ShowErrorMessage(sz_cond, func, file, line);
>        throw MyAppLogicError(sz_cond, func, file, line);
>    }
>}
>
>#define ASSERT(cond) my_assert(cond, #cond, __FUNCTION__, __FILE__, __LINE__);

void somefunc(int i)
{
   assert(i!=0);
}

somefunc(n);

if(n!=0)
    somefunc(n);
else
    ...

public class Assert 
{
public static void That(bool condition) 
{
if (!condition) throw new AssertException();
}

S>>А тестировать-то как? В смысле юнит-тестировать. Сидеть и на каждом из сотни тестов мышкой закрывать ассертовские мессаги?

public void Метод()
{
MyBLObj res = посчитайЧтонибудь();
Assert.That(res != null);
отдайКудаНибудь(res);
}

private MyBLObj посчитайЧтонибудь()
{
//...
}
private void отдайКудаНибудь(MyBLObj obj)
{
//...
}

__>a = b;
__>assert(a == b);
__>if (a != b) { return error; }
__>

if (a != b) { return error; }

if (a != b) { throw error; }

OE>void somefunc(int i)
OE>{
OE>   assert(i!=0);
OE>}

OE>somefunc(n);

OE>if(n!=0)
OE>    somefunc(n);
OE>else
OE>    ...

По мере возможности делайте интерфейсы программными, а не семантическими. Каждый интерфейс состоит из программной и семантической частей. Первая включает типы данных и другие атрибуты интерфейса, которые могут быть проверены компилятором. Вторая складывается из предположений об использовании интерфейса, которые компилятор проверить не может. Семантический интерфейс может включать такие соображения, как «Метод А должен быть вызван перед Методом В» или «Метод А вызовет ошибку, если переданный в него Элемент Данных 1 не будет перед этим инициализирован». Семантический интерфейс следует документировать в комментариях, но вообще интерфейсы должны как можно меньше зависеть от документации. Любой аспект интерфейса, который не может быть проверен компилятором, является потенциальным источником ошибок. Старайтесь преобразовывать семантические элементы интерфейса в программные, используя утверждения (assertions) или иными способами.

Документируйте выраженные в интерфейсе предположения о параметрах. Если вы предполагаете, что передаваемые в метод данные должны иметь определенные
характеристики, сразу же документируйте эти предположения. Документирование предположений и в самом методе, и в местах его вызова нельзя назвать пустой тратой времени. Пишите комментарии, не дожидаясь завершения работы над методом: к тому времени вы многое забудете. Еще лучше применить утверждения (assertions), позволяющие встроить предположения в код.

OE>вопрос поставлен некорректно,

public class MyClass
{
  public void Initialize() {
    // Как правильно:
    Debug.Assert(!IsInitialized, "!IsInitialized");
    // или
    if(IsInitialized) {
      throw new InvalidOperationException();
    }//if
    // вариант позволить несколько раз метод не рассматриваем :о)
    
    // ...
    IsInitialized = true;
  }
  
  private bool IsInitialized { 
    get; 
    set; 
  }
  
  public object GetData() {
    // Как правильно:
    Debug.Assert(IsInitialized, "!IsInitialized");
    // или
    if(!IsInitialized) {
      throw new InvalidOperationException();
    }//if

    //...
  }
}

M>3.13 Не программируйте в "защитном" стиле

void Method(string input) {
  IntPtr handle = CreateSomeObject();
  WriteStringData(handle, input.Length, input);
  CloseHandle(handle);
}

Good framework design helps the application developer realize the benefits of exceptions.

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

M>Так не передавай

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

int Method1(int index) {
  Debug.Assert(index >= 0, "index >= 0");
  return array[index];
}

void Method2() {
  Debug.Assert(!Thread.CurrentThread.IsBackground, "Should be called only from UI thread!");
  Application.Idle += delegate { };
}

void AddRef() {
  referencesCount++;
}

void Release() {
  Debug.Assert(referencesCount > 0, "No references!");
  referencesCount--;
}

void Dispose() {
  Debug.Assert(referencesCount == 0, "Reference leak!");
}

_FR>>int Method1(int index) {
_FR>>  Debug.Assert(index >= 0, "index >= 0");
_FR>>  return array[index];
_FR>>}

Do not create methods that throw NullReferenceException or IndexOutOfRangeException.

_FR>>void Method2() {
_FR>>  Debug.Assert(!Thread.CurrentThread.IsBackground, "Should be called only from UI thread!");
_FR>>  Application.Idle += delegate { };
_FR>>}

_FR>>void AddRef() {
_FR>>  referencesCount++;
_FR>>}

_FR>>void Release() {
_FR>>  Debug.Assert(referencesCount > 0, "No references!");
_FR>>  referencesCount--;
_FR>>}

_FR>>void Dispose() {
_FR>>  Debug.Assert(referencesCount == 0, "Reference leak!");
_FR>>}

inline BSTR _bstr_t::Detach()
{
    _COM_ASSERT(m_Data != NULL && m_Data->RefCount() == 1);

    if (m_Data != NULL && m_Data->RefCount() == 1) {
        BSTR b = m_Data->GetWString();
        m_Data->GetWString() = NULL;
        _Free();
        return b;
    } 
    else {
        _com_issue_error(E_POINTER);        
    }
}

1. Получит исключения, как в правильном по моему мнению примере
   
2. Программа глухо свёрнётся из-за ошибки доступа по невалидному адресу
   
3. Программа будет как-то неправильно работать

//pre a > 0 Явно в документации 
void foo(int a);

//или так(что лучше)
void foo(positive_int a);

try
{
  int a = get();
  foo(a);  // даже если get гарантирует что возвращенное значение > 0, то в foo все равно будет повторная проверка
}
catch(InvalidArgument)
{
 Message("error");
}

int a = get()
if(a > 0) // А это можно убрать если get гарантирует что a>0
  foo(a);
else
 Message("error");

L>Debug.Assert(null != table, "null != table");
L>if (null == table)
L>    throw new ArgumentNullException("table");