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 programming language

Equality operator

The classic gotcha in C is the fact that

if (a=b) code;

is syntactically valid and always correct. It puts the value of b into a and then evaluate to non-zero value if b is a non-zero value, because the expression a=b will yield the value of b. Which is different from if(a==b) which evaluate the expression that yields a truth value (typically 1 or 0, the latter representing false).

Some people might call it a gotcha, I call it incompetence, you have to be carefull and honest about your intention in C. You have to be aware of every expression.

The rest is original bullshit I didnt have to courage to correct yet so I simply deleted it.

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 <iostream>

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 JavaScript programming language

JavaScript function closures inside loops don’t work intuitively.

var func = [];
for(var i = 0; i < 3; i++) {
   func[i] = function() {
       alert(i);
   }
}
func[2]();
func[0]();

correct way:

var func = [];
for(var i = 0; i < 3; i++) {
   func[i] = (function(i){
       return function(){
           alert(i);
       }
   })(i); //HERE IT IS
}
func[2]();
func[0]();

Gotchas in Ruby programming 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 Blah
irb(main):002:1>   def foo
irb(main):003:2>     puts "I'm foo, and I got called"
irb(main):004:2>   end
irb(main):005:1>
irb(main):006:1*   def bar
irb(main):007:2>     if false then
irb(main):008:3*       foo = 1
irb(main):009:3>     end
irb(main):010:2>     puts "I am about to call foo"
irb(main):011:2>     foo
irb(main):012:2>     puts "I believe I called foo"
irb(main):013:2>   end
irb(main):014:1> end
=> nil
irb(main):015:0> x = Blah.new
=> #<Blah:0xb7d3b5b4>
irb(main):016:0> x.bar
I am about to call foo
I believe I called foo
=> nil
irb(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 always 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 }
1
2
3
=> 1..3
irb(main):002:0> (3..1).each { |i| puts i }
=> 3..1
irb(main):003:0>

Returns from the block

return statement returns from the context it was defined in, not from the context it is being executed in. For example:

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

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

Implicit array creation

Under certain circumstances, comma implicitly binds the values into an array:

irb(main):001:0> 1, 2
SyntaxError: compile error
(irb):1: syntax error, unexpected ',', expecting $end
        from (irb):1
irb(main):002:0> a = 1, 2
=> [1, 2]

So, certain typos that would be immediately noticed in other languages, would not trigger a syntax error in Ruby and may lead to some time-consuming investigations:

irb(main):001:0> def hello
irb(main):002:1>   a = 1
irb(main):003:1>   b = 2,
irb(main):004:1*   c = 3
irb(main):005:1>   d = 4
irb(main):006:1>   puts "This is my program that will say Hello to the world!"
irb(main):007:1>   if a == 1 then
irb(main):008:2*     if b == 2 then
irb(main):009:3*       if c == 3 then
irb(main):010:4*         if d == 4 then
irb(main):011:5*           puts "Hello World!"
irb(main):012:5>         end
irb(main):013:4>       end
irb(main):014:3>     end
irb(main):015:2>   end
irb(main):016:1>   puts "My program has said Hello!"
irb(main):017:1> end
=> nil
irb(main):018:0> hello
This is my program that will say Hello to the world!
My program has said Hello!
=> nil

Gotchas in DOS batch file language

One would expect that the batch file would execute commands exactly as if they were typed manually. This is not true in the particular case when one of the commands is determined to be another batch file, in which case it simply replaces the one currently being executed.

C:\test>copy con main.bat
@echo off
echo Starting main.bat
subr
echo Completing main.bat
^Z
        1 file(s) copied.
C:\test>copy con subr.bat
@echo off
echo Starting subr.bat
echo Completing subr.bat
^Z
        1 file(s) copied.
C:\test>main.bat
Starting main.bat
Starting subr.bat
Completing subr.bat
C:\test>

References

External links

Gotcha definition at The Jargon File