Exception handling and compiler option issue

[Jiang]

Hey hybrid,

As we know exception handling is disabled for irrlicht library( can be verified by visual studio solution files).

However, in irrMap.h, we have code like this (svn TRUNK, REV 1913):

Code: Select all

		// ValueType operator
		operator ValueType()
		{
			Node* node = Tree.find(Key);

			// Not found
			if (node==0)
				throw "Item not found";

			_IRR_IMPLEMENT_MANAGED_MARSHALLING_BUGFIX;
			return node->getValue();
		}

I can not explain why throw exception here.

Actually I am now using build scripts to generate irrlicht related solution files, and I disabled exception handling explicitly for both irrlicht library and the examples. However, my MingW compiler won't compile this code snippet unless I enable the exception handling.

Regards,
Jiang

[hybrid]

Yes, has been in ever since, and the map implementation doesn't fit to Irrlicht's code conventions and desing principles at all. But we don't have a better version, so we have to live with the current code and work around such issues somehow.

[Jiang]

Yes, has been in ever since, and the map implementation doesn't fit to Irrlicht's code conventions and desing principles at all. But we don't have a better version, so we have to live with the current code and work around such issues somehow.

How about just ignore the exception and crash the program [intentionally] ? As we know we have quite a few places that null-pointer dereferences were used for unexpected exceptions.

Yes, I see the difference between calling a pure virtual function and a simple map query, but IMHO it is still better than the current undefined scenario.

Regards,

Jiang

[vitek]

You can't really get C++ Standard Library semantics without taking on requirements that are similar to those used by the C++ Standard Library.

I see a few possible options, none of which are excellent.

1. Remove the check and throw and replace it with _IRR_DEBUG_BREAK_IF(!node). That would be consistent with how Irrlicht currently handles this type of thing in core::array<>. Of course this doesn't do much in a release build, but it is better than a kick in the nuts.
2. Another option would be to do like core::list<> does and just leave out the check and the exception (the iterators are unchecked)
3. Remove AccessClass and core::map<>::operator[], then require the user call find() instead.

Travis

Travis