#ifndef DEBUG
    #undef assert
    #define assert(e) (__assume(e))
#endif

СМ>double sqrt( double X ) {
СМ>assert( X >= 0.0 );
СМ>// тра-тата
СМ>}

СМ>double sqrt( double X ) {
СМ>if( X < 0.0 ) throw ....
СМ>// тра-тата
СМ>}

void aVeryBadFunction()
{
    char arr[10];
    for(int f=0;f<20;++f)
        arr[10-f-1]=f;
}

void goodFunction()
{
    std::string aString;
    aString="adfjnaksd";
    aVeryBadFunction();
    //Приплыли. Такой вот код может дать AE:
    for(size_t f=0;f<aString.size();++f)
        aString[f]=toupper(aString[f]);    
}

set_assertion_handler(throw_oops);
try
{
  for(int n=0; ; ++n) // а пёс его знает, до скольки там надо считать
    direct_access_to_nth_item(n);
}
catch(oops) // типа, конец цикла
{
}

template<bool> struct CompileTimeChecker
{
   CompileTimeChecker(...);
};
template<> struct CompileTimeChecker<false> { };
#define STATIC_CHECK(expr, msg) \
   {\
       class ERROR_##msg {}; \
       (void)sizeof(CompileTimeChecker<(expr) != 0>((ERROR_##msg())));\
   }

template <class To, class From>
To safe_reinterpret_cast(From from)
{
   {
      class ERROR_Destination_Type_Too_Narrow {};
      (void)sizeof(
         CompileTimeChecker<(sizeof(From) <= sizeof(To))>(
            ERROR_Destination_Type_Too_Narrow()));
   }
   return reinterpret_cast<To>(from);
}

static void myfuncchar *a)
{
assert(a); // не мееет смысла
}

...
myfunc("abcd");

my_assert( CloseHandle(hFile) ); // обрашение к OS

export my_error myfuncchar *a) // вызывается из вне
{
   my_assert(a);
   if( 0 == a )
       return invalid_parameter;

   return ok;
}

_>static void myfuncchar *a)
_>{
_>assert(a); // не мееет смысла
_>}

_>...
_>myfunc("abcd");
_>

_>my_assert( CloseHandle(hFile) ); // обрашение к OS

_>export my_error myfuncchar *a) // вызывается из вне
_>{
_>   my_assert(a);
_>   if( 0 == a )
_>       return invalid_parameter;

_>   return ok;
_>}

_>

Philosophers say that reality defies imagination by being more complex than what our mind can concoct. This is certainly true in the case of software development. There are tons of stories about assertions that were just "impossible to fire," but they actually fired. Time and again, it goes the same way. "This value is certainly positive! That pointer is obviously not null! The array? It's undoubtedly sorted; I'd bet money on that! Why recheck tautologies?" If you're a beginner, you feel like you are wasting your time when you write some assert, but much more often than you initially thought, it's going to fire to save your life. It's all because software development is complex, and anything could happen in a program that is changing. Assertions verify that what you believe is "obviously true" actually stays true.

There is an effective litmus test to differentiate the cases in which you need to use assert and when you need to use genuine error checking: you use error checking for things that could happen, even very improbably. You use assert only for things that you truly believe cannot possibly happen under any circumstances. An assertion that fails always signals a design or a programmer error — not a user error.

On the other hand, you do not want to use assertions to validate return values of functions that might fail. You don't use assert to make sure that malloc worked, that a window creation succeeded, or that a thread was started. You can, use, however, assert to make sure that APIs work as documented. For example, if some API function is documented to always return a positive value, but somehow you suspect it might have a bug, you might want to plant an assert.

_>static void myfuncchar *a)
_>{
_>assert(a); // не мееет смысла
_>}

_>...
_>myfunc("abcd");
_>

_>my_assert( CloseHandle(hFile) ); // обрашение к OS

_>export my_error myfuncchar *a) // вызывается из вне
_>{
_>   my_assert(a);
_>   if( 0 == a )
_>       return invalid_parameter;

_>   return ok;
_>}

_>

my_assert( CloseHandle(hFile) ); // обрашение к OS

double SomeClass::get_prop1() const
{
    assert(prop1_ > 0);
    return prop1_;
}

double SomeClass::get_ptop2() const
{
    assert(prop2_ >= 0); 
    return prop2_;
}

Н>"Настоящие" (попрошу заметить кавычки ) предпочитают как можно большее число проверок вынести в compile-time (см. Александреску, Compile-Time Assertions):

//ASSERT времени компиляции. Может быть помещён почти в любом месте программы.
#define TASSERT(COND1T1ON) typedef int TASSERT_fict1ve_namE[(COND1T1ON)?1:-1];

void fun(unsigned int x){
switch(x){
  default: __assume(0);
  case 0: F0(); break;
  case 1: F1(); break;
}

static const F_ptr[] = { &F0, &F1 };
void fun(int x){
  F_ptr[x]();
}

static const F_ptr[] = { &F0, &F1 };
void fun(unsigned int x){
  if(x<2)
    F_ptr[x]();
}

if (param == NULL)
{
    ATLASSERT(param && "Invalid parameter, but error is not critical");
    return E_FAIL;
}

I>my_assert( CloseHandle(hFile) ); // обрашение к OS
I>

BOOL bRet = CloseHandle(hFile);
ASSERT(bRet);
UNREFERENCED_PARAMETER(bRet);

double sqrt( double X ) {
assert( X >= 0.0 );
// тра-тата
}

double sqrt( double X ) {
if( X < 0.0 ) throw ....
// тра-тата
}

СМ>double sqrt( double X ) {
СМ>assert( X >= 0.0 );
СМ>// тра-тата
СМ>}

СМ>

СМ>double sqrt( double X ) {
СМ>if( X < 0.0 ) throw ....
СМ>// тра-тата
СМ>}
СМ>

double sqrt( double X ) 
{
assert( X >= 0.0 );
тра-тата
}

if (X < 0) throw...;
if (Y == 0) throw...;
...

sqrt(X);
log(Y);

Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible.

Software should be transparent in the way that it fails, as well as in normal operation. It's best when software can cope with unexpected conditions by adapting to them, but the worst kinds of bugs are those in which the repair doesn't succeed and the problem quietly causes corruption that doesn't show up until much later.

Therefore, write your software to cope with incorrect inputs and its own execution errors as gracefully as possible. But when it cannot, make it fail in a way that makes diagnosis of the problem as easy as possible.

Consider also Postel's Prescription:[10] “Be liberal in what you accept, and conservative in what you send”. Postel was speaking of network service programs, but the underlying idea is more general. Well-designed programs cooperate with other programs by making as much sense as they can from ill-formed inputs; they either fail noisily or pass strictly clean and correct data to the next program in the chain.

However, heed also this warning:

The original HTML documents recommended “be generous in what you accept”, and it has bedeviled us ever since because each browser accepts a different superset of the specifications. It is the specifications that should be generous, not their interpretation.

-- Doug McIlroy

McIlroy adjures us to design for generosity rather than compensating for inadequate standards with permissive implementations. Otherwise, as he rightly points out, it's all too easy to end up in tag soup.