Public Group

# Try, Catch, Throw, and NullObjects

This topic is 3678 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Ok, so im building my own Safe/Smart Point persay, and ive been looking into how to handle all of my Null Pointers. Ive looked at Try, Catch, and Throw, and find it to be a fairly nice solution. But i dont like having to put my try, catch statement at the beginning of my game/server loop. Ive also looked into NullObjects, which are basically objects that when you try to call something from it, it will do nothing. But i find this to possibly be dangerous when im doing calculations (for damage, attack speed, ect...) in-game or on the server. Right now, i think I will take the Try, Catch, Throw solution. But, i want a second opinion as to what i can do to "get out of there" when i have a null/corrupt pointer. Thanks, GanonPhantom

##### Share on other sites
Quote:
 Original post by GanonPhantomOk, so im building my own Safe/Smart Point persay, and ive been looking into how to handle all of my Null Pointers.

C++? boost::shared_ptr [wink]

Quote:
 Right now, i think I will take the Try, Catch, Throw solution. But, i want a second opinion as to what i can do to "get out of there" when i have a null/corrupt pointer.

What do you mean, what's wrong with a null pointer? Something like this?
bar(ptr)    if (ptr is null)        panic();    ptr->foo(9001); /*lol*/

It depends on the situation. You might want to just log and exit, or throw an exception (for example, if the renderer encounters a runtime error, throw an std::runtime_error), etc.

##### Share on other sites
Quote:
Original post by agi_shi
Quote:
 Original post by GanonPhantomOk, so im building my own Safe/Smart Point persay, and ive been looking into how to handle all of my Null Pointers.

C++? boost::shared_ptr [wink]

Sorry, i dont want to use any boost libraries in my projects, as it will be open source sooner or later, and i dont want to have to make people download/check-out alot of code.

Plus, its also a learning experience.

With the "Whats wrong with a NULL pointer" thing, its a problem when you try to call a function from a pointer that points to 0x00000000 (or sometimes the debugger shows 0x0C0C0C0C) [wink].

##### Share on other sites
Quote:
 Original post by GanonPhantomSorry, i dont want to use any boost libraries in my projects, as it will be open source sooner or later, and i dont want to have to make people download/check-out alot of code.

Any decent C++ programmer should already have Boost ready to go [grin]. Really, though, it's not "a lot of code." Boost has been rigorously tested for a very long time, it'll save you a lot of development time compared to the time it takes you to roll your own version and debug it well enough to get rid of all of the bugs.

Quote:
 Plus, its also a learning experience.

That's perfectly fine, if it was only a learning experience.

Quote:
 With the "Whats wrong with a NULL pointer" thing, its a problem when you try to call a function from a pointer that points to 0x00000000 (or sometimes the debugger shows 0x0C0C0C0C) [wink].

Well, yeah, and thus, I replied:
Quote:
 It depends on the situation. You might want to just log and exit, or throw an exception (for example, if the renderer encounters a runtime error, throw an std::runtime_error), etc.

##### Share on other sites
Quote:
Original post by agi_shi
Quote:
 Original post by GanonPhantomSorry, i dont want to use any boost libraries in my projects, as it will be open source sooner or later, and i dont want to have to make people download/check-out alot of code.

Any decent C++ programmer should already have Boost ready to go [grin]. Really, though, it's not "a lot of code." Boost has been rigorously tested for a very long time, it'll save you a lot of development time compared to the time it takes you to roll your own version and debug it well enough to get rid of all of the bugs.

I know alot of very decent C++ programmers, which none of them use boost, because they know how to handle what boost does themselves. What libraries you use doesn't reflect on how well you can program.

Quote:
Original post by agi_shi
Quote:
 Plus, its also a learning experience.

That's perfectly fine, if it was only a learning experience.

Whats wrong with managing stuff myself, it only makes me smarter and gives me a more inside scoop on how things are handled which will allow me to better structure my program in the long-run. Its an oxi-moron to say that learning is bad for you.

##### Share on other sites
Quote:
 Original post by GanonPhantomWhats wrong with managing stuff myself, it only makes me smarter and gives me a more inside scoop on how things are handled which will allow me to better structure my program in the long-run.

Reinventing the wheel does not make you smart. Though I'm bad at proving these things, so I'll stop here and let someone else do the explaining.

##### Share on other sites
Quote:
Original post by agi_shi
Quote:
 Original post by GanonPhantomWhats wrong with managing stuff myself, it only makes me smarter and gives me a more inside scoop on how things are handled which will allow me to better structure my program in the long-run.

Reinventing the wheel does not make you smart. Though I'm bad at proving these things, so I'll stop here and let someone else do the explaining.

Ok, so standing behind boost::shard_pointer, with no working knowledge of how it works will allow you to use it better in your program, and make you smarter?

Also, if we (civilization) never "reinvented the loop", there would probably not be any improvement in civilization. Because when something is reinvented (or modified persay), there will almost always be improvements.

##### Share on other sites
No one is saying you should blindly use boost::shared_ptr without understanding how it is implemented. In fact, understanding how it is implemented is crucial in avoiding the reference loops that can cause memory leaks.

As for reinventing the wheel, there may be certain cases where you can improve on what has gone before. IMO a C++ smart pointer class is not such a case. They are pretty much infrastructure now, and should really be in the standard library. AFAIK, boost's smart_ptr interface is what will be used for the next C++ standard library, which will include a smart pointer (it may already be available in a suppementary namespace in your standard library). You could probably download a reasonably well used and tested implementation of some smart pointer interface from a number of sources, rather than spend valuable developer time doing it yourself.

As for your questions, I would use assert() for situations that should never happen (e.g. calling operator*() or operator->() on a null smart pointer). Exceptions really should only be used for situations where it is reasonable to recover. It is context dependant, but calling such an operator on a null smart pointer is usually a serious logic error and the programs state may be undefined no matter what you do.

I wouldn't go into the NullObject idea. While I can think of maybe a few domain specific situations where it might have merit - it isn't really a general purpose solution to the problem.

##### Share on other sites
ok, thx for the reply rip-off :)

For assert(), is there a way to make it not pop up with a message box, and continue execution (to the front of the thread loop)? As this is a Server Emulator, and stopping the execution while there are hundreds of people are online isnt really ideal.

Thx for the formal reply thought,
GanonPhantom

##### Share on other sites
Quote:
 Original post by GanonPhantomok, thx for the reply rip-off :)For assert(), is there a way to make it not pop up with a message box, and continue execution (to the front of the thread loop)? As this is a Server Emulator, and stopping the execution while there are hundreds of people are online isnt really ideal.Thx for the formal reply thought,GanonPhantom

assert() is for situations that are never supposed to happen, it exists only in debug mode. It's not meant to continue executions - that's what logging is for. Don't log inside the pointer; like I said, check the point if it's null in the block of code that uses it, and if so, act appropriately.

1. 1
2. 2
frob
16
3. 3
4. 4
5. 5

• 15
• 13
• 14
• 75
• 22
• ### Forum Statistics

• Total Topics
632145
• Total Posts
3004345

×

## Important Information

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!