I think handling exceptions in C++ is more expensive than simply check a boolean value .... (?)

I think that loading textures has lots of reason to fail (file not found, memory problem, etc.. )[/quote]
Run-time part typically has no failure modes. There is exactly nothing end user can do if any of these are a problem.

Either the desired texture is loaded or stub is used. An engine which displays occasional wrong texture is better than one that doesn't run. Whether it's memory, missing file, corrupt data - the spice must flow...

Tools might behave differently, reporting a missing texture, but that would be considered a hard error. Either way, editor must continue not only to be able to open the file, but also preserve missing resources.

Vincent,

Allocating memory from the heap is a messy expensive process. C++ responds to this by never using the heap unless you explicitly tell it to (by calling "new").

The vast majority of objects exist on the stack. That is, when you call a function, the stack pointer jumps by enough to allow space for every object local to that function. That way it doesn't need to muck around with allocating memory for them, and when the function returns, the pointer jumps back to where it was before the function call and the program "forgets" about the objects that were in that space (which then gets reused by the next function call). Efficient, simple, and no heap allocations to clean up.

The implication though, is that the constructor actually has nothing to do with the allocation of memory for holding the object itself. The actual memory that holds the object might have been allocated by "new", or might be on the stack. The constructor doesn't know. By the time the constructor is run, the object (though yet to be initialized) already exists, so the constructor can't decide not to make one. That's why it doesn't return a pointer ("new" does), and can't return "null".

The basic rule of dynamic memory usage is "if you create it, you're responsible for destroying it", which leads to the generally true, "If you didn't create it, you're not allowed to destroy it. Hell you don't even know if it can be destroyed." Which leads us to, "Since the constructor didn't allocate the memory for the object, the constructor can't deallocate it".

Now programs do routinely pass responsibility for dynamically allocated objects on to others. But in order to allow the object's constructor to assume responsibility for the object's own heap storage, it must only ever be called for a dynamically allocated object. In other words you must somehow never allow one to exist on the stack. And the constructor must then somehow pass the responsibility on to something else if it decided not to destroy itself.

Anyway, +1 to the "Factory". One way to structure it to get the behavior you seem to be after might be something like:

struct TGATextureData;

class TGATexture
{
  private: // Objects of this class can *only* be created by members of this class.
    TGATexture(); // Unimplemented.
    TGATexture(TGATextureData *); // The factory uses this one.

  public: // This factory is the only way to get a TGATexture object.
    static TGATexture * GetTexture(char const * filename);
    ...
};
...

TGATexture * TGATexture::GetTexture(char const * filename)
{
    TGATextureData * pTextureData = LoadTGATextureData(filename);
    if(pTextureData == nullptr)
    	return nullptr;

    return new TGATexture(pTextureData);
}
...

TGATexture * pTexture = TGATexture::GetTexture(filename);
if(pTexture != nullptr)
{ ... }

Where LoadTGATextureData() is a static helper function which can try and fail to load the given file.