Exception catching

[_rewinder_]

Well, i have a new problem since updating to 1.0.0RC1
I have a function wich gets a material name and texture name. It throws Ogre::Exception if there is no material wirh such name. But if material exists, it tries to set new texture name to some texture unit.
I'm catching Ogre::Exceptions exactly after function call, i.e:

Code: Select all

try
{
myFunction(material, texture)
}
catch (const Ogre::Exception& e)
{
std::cout << e.getFullDescription() << std::endl;
}

But this code catches only my exceptions (which are thrown in myFunction), and ResourceManager exceptions (which are thrown if there is no texture with such filename) aren't catched.

BR, rewinder

[bal]

Hmm, can't you handle all the Ogre Exceptions in the "big" exception-handling structure (like in the example applications) ? A try-catch structure for every function seems a bit overkill to me and not so efficient.

[_lkoikm]

well if we are talking ablout visual c++ ( as everyone knows visual c++ is somehow diffrent from borland c++ or any other and MS compilers have their humours )
if your code is managed you could write

Code: Select all

try 
 {
   f(par1,par2);
 }
catch (System::Exception *e)
 {

 }

or

Code: Select all

catch(...)
{
}

which allows you to catch every exception but you lost info what was the exception...

i would like someone to correct me if i was wrong since that would enlighten me

[_rewinder_]

Hmm, can't you handle all the Ogre Exceptions in the "big" exception-handling structure (like in the example applications) ? A try-catch structure for every function seems a bit overkill to me and not so efficient.

I should handle exceptions exactly after function call, because if i'll handle exceptions in the main() function execution of program will go to the root of call stack, so program quits immediatly.

catch(...)
{
}

I have tryed it yet, but it doesnt work too.

It seems to me that the motive of problem is multithreaded ResourceManager structure.

[sinbad]

Are you absolutely sure there is an exception being thrown? You don't say which methods you're calling, but getByName for example does not thrown an exception, it returns a null shared pointer.

It's should be nothing to do with the ResourceManager threading issues, because a) they're all disabled by default, and b) threading doesn't affect exceptions anyway (except that you can only catch them in the thread they're they're thrown in, of course).

[_rewinder_]

Are you absolutely sure there is an exception being thrown? You don't say which methods you're calling, but getByName for example does not thrown an exception, it returns a null shared pointer.

Yes, if MaterialManager::getByName() returns null pointer, i throw exceptions by myself.[/code]

[sinbad]

Then I suspect you have a problem in your own code. We throw / catch exceptions in the OGRE code on a regular basis (it's our chosen method of reporting errors) and don't have any issues. The demos ultimately catch exceptions which are not handled in the engine itself and I guarantee that works fine.

[fractile]

I have seen similiar behaviour, when throwing and catching code has been compiled/linked with different kind pthread flags..