Opinion - Should createDevice throw when returning null?

[Dreadstew]

Hi, I just started up a game and got sucked into little details. We have to check the returned pointer from createDevice and calls like device->getDriver(). It would clean up client code to have them throw an exception when returning NULL. What do you think? I'll add it if people want it. If it generally sounds like it would just get in your way I get that.

I guess I'm not sure how to contribute really, how do we contribute? Am I right that calls like getMesh("path/path/path.obj") are synchronous? I want to add a async one as well.

[hendu]

Exceptions add overhead, which is often unacceptable.

[CuteAlien]

Yeah, Irrlicht mostly doesn't use exceptions (only exception to that are memory allocations which can throw bad_alloc).

Also even when using exceptions - they shouldn't be used for this. This is just normal error handling and one shouldn't use exceptions for that. The way to use exceptions would be for example when you have a "Device" class in your own code which tries to create an Irrlicht device in it's constructor - and now you need a way to inform the rest of your code that this has failed.

[Mel]

Why don't you throw yourself an exception if you need it? check the device, and throw it for yourself, not everybody uses exceptions

[Dreadstew]

I knew it wouldn't be a popular idea lol. I agree with you all except Mel, the point of irrlicht throwing the exception would be to keep my code cleaner, I'd only have to wrap everything in a try catch

[chronologicaldot]

Come to think of it, nothing in Irrlicht throws exceptions that I know of, even when unrelated to draw calls. Coding habit, maybe? I guess the manta is "It better work, not 'or else'."

[AReichl]

> Exceptions add overhead, which is often unacceptable.
"Overhead" in C++ is less "overhead" than in other languages (where sometimes you HAVE to use exceptions, and no one is complaining).
And with newer compilers the overhead is only there when the situation arises (meaning an exception is really thrown).

[hendu]

Overhead includes size too. It's easily 5-15% more size just by enabling exceptions, even if modern compilers reduce the runtime and memory overhead.

[MartinVee]

My two cents... I really don't see why/how a try..catch block is cleaner than checking for nullptr.

[CuteAlien]

In this specific case exceptions don't fit. There's no way replacing return values by exceptions is a good idea, that's exception abuse. There is nothing going wrong in Irrlicht here - it's correctly returning a null-pointer. Your user-code might require exceptions certainly for this case and the way to do that is exactly like Mel said, something like: "if ( !devicePtr) throw MyException".

I think the discussion by now is more about exceptions in general. Got to admit I haven't checked in a while how expensive they are. I use them sometimes in my own code, but not much. Do they really add that much size? This sounds more like RTTI (which will have to add some bytes to objects).

I don't think there are many places inside Irrlicht where exceptions would make sense to use. Irrlicht doesn't work much with RAII (allocating resources in constructors and releasing them in destructors, so basically wrapping resources into class-objects) for which exceptions are most useful. There might be some internal code which could look nicer with exceptions, but not a big deal really. And I can't think right now where it might have to pass any exceptions out of Irrlicht, though I guess if I really searched for it I might find a place or two where it would be a theoretical alternative (but not enough gain to introduce them in the lib).

edit: There is btw another reason to avoid throwing exceptions out of a library. This can cause some problems when they are thrown across dll borders. At least older g++ versions had some troubles there on Windows if I remember correct.

[Dreadstew]

Ight, no exceptions then! The common idea behind exceptions increasing size - I think they just mean code size. I was throwing exceptions after checking for null pointer, but instead I decided to just use MessageBox and display an error. Got my init code all jazzed up with error checking! lol... that's all I have done so far. Took me a day. I even let the user pick a new working directory if files wouldn't load and store it in the ini.txt lol.

[Mel]

Exceptions are just that, "exceptions", things that shouldn't happen but that may happen. I think it is much safer to think in advance of all the posible outcomes of a function, and leave the exceptions as rare cases that can't be avoided by simply dodging the code that may cause problems. Exceptions cause the program to abruptly interrupt its execution, safeguard the process state, and execute the routine that handle the exception. I take those are error states, and programs should be as free from errors as possible, being the zero exceptions the ideal case, in a nutshell. Exceptions are okay for debugging, but in production compilations, i think it should be possible to not to use them at all, and be able to handle all the program errors as part of the program itself, without exceptions. But that is just my opinion.

[chronologicaldot]

One place in Irrlicht that could probably use Exceptions is the irrArray::operator[]() . It assumes the index is always in bounds, so when it isn't, it can be tricky to catch. There are probably other spots, but it doesn't seem worth it. If I wanted exceptions, I would probably add macros for enabling/disabling them.

[Dreadstew]

For my latest project I have disabled exceptions completely even for debug lol. I agree with Mel, any exception code should compile out in release mode unless you have a really good reason.