Why does this cause an exception if the entity isn't found?
Why do I have to itterate through all the entities to see if it is loaded or not when the getEntity already itterates through to locate the item?
IMHO I think this function and Ogre:SceneManaqger::getSceneNode should return a NULL if the item wasn't found. It seems a waste of time to re-itterate through a list of objects once it was already done or to write code everywhere that I need to find out if an Entity or SceneNode is already loaded.
Longstreet's right, catching the exception is the way to go. Checking return codes is a very C way to do it. If you're using C++ then use the facilities of the language!
Well, it depends on how often the function is called. Exceptions can be very bad for performance if they occur around often used functions - say in a loop for instance.
That would be my point exactly. Ogre doesn't create entities on it's own, so if you have an entity you should know what it is. Asking for something that you created with the wrong name is clearly an exceptional condition.
And if you're using tight loops, you shouldn't be looking things up by name anyway - that suggests you're not organising your data usage very well.
sinbad wrote:That would be my point exactly. Ogre doesn't create entities on it's own, so if you have an entity you should know what it is. Asking for something that you created with the wrong name is clearly an exceptional condition.
So what? Return a NULL instead of throwning an exception. If the user doesn't handle the NULL pointer then a runtime exception will occur anyway. Testing for NULL is cheap and fast.
@Robbob: Exceptions can not only be bad for performance, but good too. For instance, when you don't test in your code for a seldom arising condition, but let a catch handle it, even when it isn't really an error but, well, the exception from the rule.
So, in Java it is considered good practice (well, not by all maybe) to not test for eof (-1) while reading from a FileInputStream, but just read and let the EOFException happen. The try-catch-overhead is small compared for what you gain for ommiting the test.
@Van: Compare yourself "Access violation in address 0xab34e41b accessing memory in 0x000001a7" or "An Exception has been thrown - No entity called XY found." Which one is more expressive?
Expressing an error condition with expections is a clear right-in-your-face-way. An exception is thrown, you don't handle it, you get a clear message. Forgetting a test for NULL isn't that expressive, it might sometimes not even do anything, depending on the pathes through your code. According to Murphy such code works fine with your test data, but explodes right in the face of your customers.
@Van: I'm afraid you're rather stuck in the C-style way of doing things. As tanis says, testing everything for null has it's own performance issues and clutters code unnecessarily with if (blah == NULL) on every return. If something is exceptional ie should not happen unless someone screws up, it should not cause the code to become more cluttered - having to check every return value for NULL does exactly that.
Exceptions are a well recognised way to deal with exceptional error cases without cluttering your code. The fact that they cascade means your nasty error checking code only has to be written in strategic places, not everywhere. You should get used to using them.