Of course, the situation where you're not mearly doing a "find" operation on a database, but you're creating (or using) an object that is made up from data in the database, then it is a suitable place to throw.

For example. A class that encapsulates a database object should throw if it can't construct.

Of course, the constructor of this object will probably call "find". "Find" itself should return an error code which the object's function/constructor should check and throw if appropriate.

Similar to file-reading. You probably don't want your "read" function to throw, however an object (like a sound object as we're discussing) should check for that failure and throw.


This is detailed by the fact that - if you were to throw from a "Find" or "Read" function, you'd simply have to immediatly catch and rethrow in order to add the relevent information about what the object was actually trying to do.


More generally, if the error will be caught by the immediate caller which will immediatly handle it, may as well use a return value - it's less code and is more readable and maintainable.

I am not sure the sound analogy is a great one.
In my experience, both for sounds and textures, if the end-user has messed with their installation, and perhaps moved the texture files, etc. then the texture class should log a warning that the file could not be found, and use a blank white texture instead.

Whereas with the exception throwing method, the code that requested a texture load would have to catch the exception, and then create a new blank texture.

I agree that if it is a major part of your game world, such as the main character model, that the program should probably terminate, but this should be done by calling code, which can decide how necessary the model is, not by the model loading code itself.