assert.h

What does /prog/ think about assertions?

By example, suppose you are developing a library, and you have a function like this:

/** Serves the foo.
 *
 * @param request The request id, which must be an odd number.
 */
int foo (int request);

Obviously you should implement some kind of checking in order to avoid bad jokes during execution, so you may be tempted to do something like

#include <assert.h>

int foo (int request)
{
    assert(request % 2);
    ...

I think this is a good design, since it makes the API more simple and it doesn't need an error management procedure. Obviously this is not the case when the error depends on - say - the content of a file, which may be non-deterministic.

The drawback is of course the crash of the whole application, but this is responsability of the developer who's using the library, since the documentation prohibits to insert even values as parameter of the foo function.

What do you think?

Assert macros are usually good ideas regardless of language, but they should not be confused with continuable errors (exceptions, conditions, whatever your language, environment or platform provides). An assertion is most likely not a continuable error, so it should only be used in fatal situations; for the rest of the cases, use something milder which can be continued (such as an error code, or setting a last error parameter, or throwing an exception, using signals, conditions - depending on the language and platform in use).

>>2
A wise suggestion, thanks.

>>1
Compile-time assertions are even more useful for those types of things.

>>4
But not always possible. How can you... wait, IHBT.

I've found little use for them, since in my case, foo would crash anyway if it was given an even parameter.

>>6
Is there a way to make the whole stuff a little more informative? Passing an even parameter might be a documentation misread or an invariant not verified!

In this case finding the error may be troublesome. By using the assertion this can be easily localized instead.

Assertions are just good coding practice. From what I've seen, Design by Contract is just the logical extension of this and PLT makes it pretty usable. Presumably the Nazi-typed languages like Haskell just use guards and have their type-checker do the work.

I usually use assert to verify the status of internal variables, that no user of the library could ever modify - class invariants and the like. For function call parameters, I just throw WTFAreYouDoingExceptions or something along those lines (something recoverable, anyway), unless the code is performance critical in which case asserts that compile away are a better choice.

>>9
invalidCamelCase

I try not to use assertions and, instead, I try to build a response condition.  I determine a range of valid values and write statements to correct or re-rail that variable should it veer out of scope due to calculation exuberance or human error (I name the least destructive value in range as the default).

For functions and their ilk (methods, etc..) that means checking every essential parameter as it comes in.  The importance of the variable determines how it is handled; but, I try to avoid stopping the program (or, worse, the program coming to a stop) until the user wants it to at all costs.

Some people call this wasteful, but I think it's very thorough and careful as long as you have enough wriggle room.

>>10
Why? Class and namespace names start with a capital, function and variable names don't.

>>12
Camels only have humps in the middle.

>>13
Most also have a head though.

>>14
They also have a tail, several legs, ... but having your code reflect that would be ludicrous.

>>15
int ProperCamelCaps_;

>>15
Unless you're coding perl :3

                                 $_='ev
                                       al("seek\040D
           ATA,0,                  0;");foreach(1..3)
       {<DATA>;}my               @camel1hump;my$camel;
  my$Camel  ;while(             <DATA>){$_=sprintf("%-6
9s",$_);my@dromedary           1=split(//);if(defined($
_=<DATA>)){@camel1hum        p=split(//);}while(@dromeda
 ry1){my$camel1hump=0      ;my$CAMEL=3;if(defined($_=shif
        t(@dromedary1    ))&&/\S/){$camel1hump+=1<<$CAMEL;}
       $CAMEL--;if(d   efined($_=shift(@dromedary1))&&/\S/){
      $camel1hump+=1  <<$CAMEL;}$CAMEL--;if(defined($_=shift(
     @camel1hump))&&/\S/){$camel1hump+=1<<$CAMEL;}$CAMEL--;if(
     defined($_=shift(@camel1hump))&&/\S/){$camel1hump+=1<<$CAME
     L;;}$camel.=(split(//,"\040..m`{/J\047\134}L^7FX"))[$camel1h
      ump];}$camel.="\n";}@camel1hump=split(/\n/,$camel);foreach(@
      camel1hump){chomp;$Camel=$_;y/LJF7\173\175`\047/\061\062\063\
      064\065\066\067\070/;y/12345678/JL7F\175\173\047`/;$_=reverse;
       print"$_\040$Camel\n";}foreach(@camel1hump){chomp;$Camel=$_;y
        /LJF7\173\175`\047/12345678/;y/12345678/JL7F\175\173\0 47`/;
         $_=reverse;print"\040$_$Camel\n";}';;s/\s*//g;;eval;   eval
           ("seek\040DATA,0,0;");undef$/;$_=<DATA>;s/\s*//g;(   );;s
             ;^.*_;;;map{eval"print\"$_\"";}/.{4}/g; __DATA__   \124
               \1   50\145\040\165\163\145\040\157\1 46\040\1  41\0
                    40\143\141  \155\145\1 54\040\1   51\155\  141
                    \147\145\0  40\151\156 \040\141    \163\16 3\
                     157\143\   151\141\16  4\151\1     57\156
                     \040\167  \151\164\1   50\040\      120\1
                     45\162\   154\040\15    1\163\      040\14
                     1\040\1   64\162\1      41\144       \145\
                     155\14    1\162\       153\04        0\157
                      \146\     040\11     7\047\         122\1
                      45\15      1\154\1  54\171          \040
                      \046\         012\101\16            3\16
                      3\15           7\143\15             1\14
                      1\16            4\145\163           \054
                     \040            \111\156\14         3\056
                    \040\         125\163\145\14         4\040\
                    167\1        51\164\1  50\0         40\160\
                  145\162                              \155\151
                \163\163                                \151\1
              57\156\056

>>18
what do you expect me to do, run that?

>>19
It is valid Perl code, so why wouldn't you?

>>20
Because of the hidden rm -rf's.

>>21
this is not ubanto, faggot

>>20
not the way you kopiped it, asshole. that perl code seeks to the beginning of itself and skips the first 3 lines, expecting them to be the shebang and use strict, plus a blank newline.

not the mention you fucked up the top of the hump. you're worthless.

26 Name: Anonymous 2011-02-04 12:48

<