For the non-Delphi programmers out there, self is like this in curly brace languages (C++, C#, Java). It might happen, it you mess things, that yo are debugging a method and realize that self (the object the method is being applied to) is nil, meaning there is no object. Quite often this result in an access violation as you start doing something the data of the the non-existing object.

At times, an object is nil because the constructor that should have returned it failed with an exception (a very spacial case because the object destructor is automatically executed, at least in Delphi). Similarly, an object can be nil because the function that should have returned the reference to the object failed with an exception. This was my case. In a very complex piece of code (with 5 levels of nested try(finally/except blocks) I ended up with code like:

try
  obj := GetObjectFromPool (...);
  obj.DoThisAndThat;
finally
  obj.ReleaseObject;
end;

Now this is trivially wrong, but those statements are 70 lines of code apart, not really easy to spot. Also, in theory GetObjectFromPool should never fail, or at least this is far from common. Also, I cannot really move the GetObjectFromPool call outside of the finally block (again, the code is quite convoluted), so I had to resort to a far-from-clean:

finally
  if Assigned (obj)
    obj.ReleaseObject;