Gotcha (programming)

In programming, a gotcha is a feature of a system, a program or a programming language that works in the way it is documented but is counter-intuitive and almost invites mistakes because it is both enticingly easy to invoke and completely unexpected and/or unreasonable in its outcome.

Gotchas in the C programing language

Equality operator

The classic gotcha in C is the fact thatif (a=b) code;is syntactically valid and sometimes even correct. It puts the value of b into a and then executes code if a is non-zero. What the programmer probably meant wasif (a=b) code;which executes code if a and b are equal. To avoid this gotcha, it is recommended to keep the constants in the left side of the comparison, i.e. 42 = meaning_of_life rather than meaning_of_life = 42.

Function calls

Example from computer languages such as C:
#includefoo() { printf("42");}
#if 0 /* This function declaration is INCORRECT. There have to be parentheses. * If you want to see the compiler error message, please remove the whole #if and #endif lines */bar {}
#endifmain() { foo; /* does NOTHING, it just gets the address of the function foo and does nothing with it. */ foo(); /* prints 42 */}

Gotchas in the C++ programming language

Initializer lists

In C++, it is the order of the class inheritance and of the member variables that determine the initialization order, "not" the order of an initializer list:
#include

class CSomeClass{ public: CSomeClass(int n) { std::cout << "CSomeClass constructor with value "; std::cout << n << std::endl; ;

class CSomeOtherClass{ public: CSomeOtherClass() //In this example, despite the list order, : obj2(2), obj1(1) //obj1 will be initialized before obj2. { //Do nothing. } private: CSomeClass obj1; CSomeClass obj2;};

int main(void){ CSomeOtherClass obj; return 0;}

Gotchas in Ruby programing language

Scoping

Scope of a local variable starts at its definition and ends at the end of the method. Within its scope, the local variable obscures current object's methods.

irb(main):001:0> class Blahirb(main):002:1> def fooirb(main):003:2> puts "I'm foo, and I got called"irb(main):004:2> endirb(main):005:1>irb(main):006:1* def barirb(main):007:2> if false thenirb(main):008:3* foo = 1irb(main):009:3> endirb(main):010:2> puts "I am about to call foo"irb(main):011:2> fooirb(main):012:2> puts "I believe I called foo"irb(main):013:2> endirb(main):014:1> end=> nilirb(main):015:0> x = Blah.new=> #irb(main):016:0> x.barI am about to call fooI believe I called foo=> nilirb(main):017:0>

Iterating Range

Ruby has a data type called Range; an object of this type constitutes a set of everything between the start and end of the range (including or not including the boundaries, depending on additional conditions). Since Range is a subclass of Enumerable, one would intuitively expect that iterating a valid Range object will give you every single object in that set, from start to end. This expectation turns out to be incorrect:

irb(main):001:0> (1..3).each { |i| puts i }123=> 1..3irb(main):002:0> (3..1).each { |i| puts i }=> 3..1irb(main):003:0>

Returns from the block

return statement returns from the context it was defined in, not from the context it's currently executed in. For example:

def boo() transaction do ... return if(something) ... endend

One might expect that return would allow the transaction to be properly closed, but unfortunately that's not the case -- the code in transaction() taking care of that will never be executed if something=true.

Implicit exception catching

begin ...rescue => err ...end

One would expect that the rescue block would catch any exception thrown, but this is not true -- it will only catch RuntimeError (which is a subclass of StandardError, which in turn is a subclass of Exception). If you intend to catch all exceptions indeed, the following syntax should be used:

begin ...rescue Exception => err ...end

External links

* [http://www.hyperdictionary.com/computing/gotcha from the HyperDictionary]