Opinion - Should createDevice throw when returning null?

Post your questions, suggestions and experiences regarding game design, integration of external libraries here. For irrEdit, irrXML and irrKlang, see the
ambiera forums

Opinion - Should createDevice throw when returning null?

Postby Dreadstew » Mon Mar 12, 2018 5:53 am

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.
Dreadstew
 
Posts: 11
Joined: Wed Apr 01, 2015 5:18 pm

Re: Opinion - Should createDevice throw when returning null?

Postby hendu » Mon Mar 12, 2018 9:23 am

Exceptions add overhead, which is often unacceptable.
hendu
 
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Opinion - Should createDevice throw when returning null?

Postby CuteAlien » Mon Mar 12, 2018 11:07 am

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.
IRC: #irrlicht on irc.freenode.net
Code snippets, patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Free racer created with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
User avatar
CuteAlien
Admin
 
Posts: 8528
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

Re: Opinion - Should createDevice throw when returning null?

Postby Mel » Mon Mar 12, 2018 6:33 pm

Why don't you throw yourself an exception if you need it? check the device, and throw it for yourself, not everybody uses exceptions :)
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2271
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: Opinion - Should createDevice throw when returning null?

Postby Dreadstew » Mon Mar 12, 2018 9:15 pm

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
Dreadstew
 
Posts: 11
Joined: Wed Apr 01, 2015 5:18 pm

Re: Opinion - Should createDevice throw when returning null?

Postby chronologicaldot » Tue Mar 13, 2018 5:12 am

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'."
User avatar
chronologicaldot
Competition winner
 
Posts: 560
Joined: Mon Sep 10, 2012 8:51 am

Re: Opinion - Should createDevice throw when returning null?

Postby AReichl » Tue Mar 13, 2018 9:06 am

> 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).
AReichl
 
Posts: 240
Joined: Wed Jul 13, 2011 2:34 pm

Re: Opinion - Should createDevice throw when returning null?

Postby hendu » Tue Mar 13, 2018 11:37 am

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.
hendu
 
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Opinion - Should createDevice throw when returning null?

Postby MartinVee » Tue Mar 13, 2018 12:50 pm

My two cents... I really don't see why/how a try..catch block is cleaner than checking for nullptr.
MartinVee
 
Posts: 130
Joined: Tue Aug 02, 2016 3:38 pm
Location: Québec, Canada

Re: Opinion - Should createDevice throw when returning null?

Postby CuteAlien » Tue Mar 13, 2018 1:45 pm

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.
IRC: #irrlicht on irc.freenode.net
Code snippets, patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Free racer created with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
User avatar
CuteAlien
Admin
 
Posts: 8528
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

Re: Opinion - Should createDevice throw when returning null?

Postby Dreadstew » Tue Mar 13, 2018 10:21 pm

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.
Dreadstew
 
Posts: 11
Joined: Wed Apr 01, 2015 5:18 pm

Re: Opinion - Should createDevice throw when returning null?

Postby Mel » Wed Mar 21, 2018 10:54 am

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.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2271
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: Opinion - Should createDevice throw when returning null?

Postby chronologicaldot » Wed May 02, 2018 8:45 pm

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.
User avatar
chronologicaldot
Competition winner
 
Posts: 560
Joined: Mon Sep 10, 2012 8:51 am


Return to Game Programming

Who is online

Users browsing this forum: No registered users and 1 guest