• 15
• 15
• 11
• 9
• 10
• Similar Content

• Hello all!
I'm currently designing a 2D, Puzzle/Action RPG, in a similar vein to Legend of Zelda: Link to The Past, in Unity and require a Programmer partner in which to work with me.
The project, yet to be titled, will feature:
A semi-open world, represented through pixel art, in which the player traverses to enter dungeons and advance the story. A handful of side-quests that require memorizing details and using puzzle-mechanics. A fast-paced, melee combat system that will include dodging, blocking and utilizing four different attack types that can be switched on the fly. A simple inventory of "Key Items" to be used in order to advance the story. Day & Night system and Weather Effects, with weather effecting combat.  A very simple Dialogue System to convey information via colored text. Saving/Loading via exporting and importing a physical save file. Majority of the project is already planned out, with plans to release commercially and splitting the profits equally among the two of us.
I would request that the applicant is able to work semi-independently, following an outline, and that they have experience in both C# programming  *and* putting those scripts to use inside Unity, whilst I will be creating the Art, Music/SFX and doing Level Design (Though if you are also comfortable in assisting me with these, I wouldn't be opposed.).

Work will be shared in either Github or Unity Collab (Applicants preference), with communication done via Discord.

• By Just4lol
Hello,
I'm looking for my dream teammate(s) to help me work on my Unity game. I still dont know where Im going with that project but I want to make a good final product that I would be able to sell or publish it for free on Steam.  Here a video of the prototype (The only thing I dint made is the skybox) https://www.youtube.com/watch?v=y2Otmt9jRkc
My discord : Just4lol#46982
I want somone at least as competent as me :
- I want somone with at least one year of experience in Unity (already worked with scriptable object and know oop).
- Already worked with shaders or can do editors tools is a plus.
- Can do 3d models in Blender or can do 2d art for the ui or particles effects.
- Can make soundtracks or sound effects a bonus.
Im a french Canadian so mind my english I will do my best to edit any errors I see.

• I am looking for talents to form a team of making a strategy base action game. Talents I am currently looking for are : -
(I) Unity programmer (mobile)
(II) Game designer
(III) 3d Artist
(IV) SFX Artist
The attachment is some game concept for the game. All the concept will be turn into 3d or card form. The game will be strategy game where the players can form their own team and control the units in the battle field real time to fight against each others.  If you are interested to know more details please pm me or send an email to damnwing0405@gmail.com

• By bsudheer
Leap Leap Leap! is a fast-paced, endless running game where you leap from rooftop to rooftop in a computer simulated world.

This is a free run game and get excited by this fabulous computer simulated world of skyscrapers and surreal colors in parallax effect. On your way, collect cubes and revival points as many as you can to make a long run.

Features of Leap Leap Leap:
-Option of two themes: Black or White.
-Simple one touch gameplay.
-Attractive art.
-Effective use of parallax.
Appstore: https://itunes.apple.com/us/app/leap-leap-leap/id683764406?mt=8

• By BillyGD

Play Flick Football 3D @ https://gamejolt.com/games/flickfootball3d/326078
Flick Football 3D is a turn based football game inspired by the table top classic 'Subbuteo'.
The game is currently in very early Alpha development. There is still a lot to be done before the first proper release but I have decided to release this playable version to get as much feedback as possible.
The only game mode currently available in this release is the 'Practice Mode' which gives you control of both teams. Either play against yourself to get used to how the game works or play against friends and family on the same computer!
Planned Future Features Include:
-Take control of your own custom team in the single player campaign.
-Play in online leagues and tournaments against other players in the multiplayer mode.
-Fully customisable stadiums to make you stand out from the rest of the players.
-Improve your players stats and skills by playing matches and setting up training sessions.
Flick Football 3D is available for Windows, Mac and Browser.
Thank you for viewing my game, all feedback is greatly appreciated. I can be contacted at; BillyGDev@outlook.com
'Flick Football 3D' is also the development name for the game and I haven't yet decided what the full release will be called, so if you have any ideas please drop me a message!

Unity [C++] Exceptions using them right

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

Recommended Posts

EDIT: seems like some questions below are answered here as well: http://www.gamedev.net/community/forums/topic.asp?topic_id=569089 I'm fairly new with exceptions, I don't use them much myself but I'd like some advice :) 1. Is it generally a good idea to put a throw specifier in a function definition? Like: void f() throw(std::bad_alloc); void f() {} 2. I guess it is, does it also make sense to set the throw specifier for functions that do not throw anything? 3. What to do when in debug build there's more throws then in release mode? Or is this a malformed design? Like when a function does throw in debug mode, but doesn't in release mode. How would you define the function prototype? Dependent on whether its debug/release? 4. Should I catch memory / third-party-library exceptions, handle them correctly and re-throw it? Or catch them and then throw my own exception class instead? 5. There's a difference between logging, warnings, fixable errors (like, when input is incorrect it could take a default sometimes) or regular errors. Which are best to be thrown? For debug? For release? Where do you make a distinction, or do you also use a second method for error reporting then exceptions? I generally feel like exceptions produce quite a bit of bloat in the executable. Of course, for debug mode this is no problem. In debug mode we want to debug and thus good error reporting. In release I suppose only critical errors are relevant... Thanks for the input!

Share on other sites
Quote:
 Original post by DecriusI'm fairly new with exceptions, I don't use them much myself but I'd like some advice :)
Use exceptions only in exceptional circumstances.
Quote:
 1. Is it generally a good idea to put a throw specifier in a function definition? Like: void f() throw(std::bad_alloc); void f() {}
No. Avoid using throw specifiers in C++. They do not do what you think they do. They are a deprecated language feature. Do not use them.
Quote:
 2. I guess it is, does it also make sense to set the throw specifier for functions that do not throw anything?
No, not at all.
Quote:
 3. What to do when in debug build there's more throws then in release mode? Or is this a malformed design? Like when a function does throw in debug mode, but doesn't in release mode. How would you define the function prototype? Dependent on whether its debug/release?
This should not occur. Either you can handle an exception or you can't.
Quote:
 4. Should I catch memory / third-party-library exceptions, handle them correctly and re-throw it? Or catch them and then throw my own exception class instead?
If you can't handle an exception, ignore it and let someone else handle it. That's the point of exceptions. If you can handle it, don't rethrow it, it's been handled.
Quote:
 5. There's a difference between logging, warnings, fixable errors (like, when input is incorrect it could take a default sometimes) or regular errors. Which are best to be thrown? For debug? For release? Where do you make a distinction, or do you also use a second method for error reporting then exceptions?
Use exceptions only for exceptional circumstances. Input errors are not exceptional, they are expected.
Quote:
 I generally feel like exceptions produce quite a bit of bloat in the executable.

Feelings should have little to do with it. Exceptions do not add bloat and they do not affect the nonexceptional execution path in any meaningful way. Applications that use exceptions correctly tend to be larger than those that do not handle errors at all, which is the usual comparison.

Do not confuse C++ with Java exceptions. Java exceptions are more akin to the C method of passing status values ads return values. They are two different paradigms.

Share on other sites
Quote:
 Original post by Decrius1. Is it generally a good idea to put a throw specifier in a function definition? Like: void f() throw(std::bad_alloc); void f() {}2. I guess it is, does it also make sense to set the throw specifier for functions that do not throw anything?
No. These specifiers have always been somewhat problematic for no benefit.

Quote:
 3. What to do when in debug build there's more throws then in release mode? Or is this a malformed design?
Yes. Interfaces should be consistent. There is no "debug mode" in C++, it's just a preselected set of compiler switches - application doesn't change.

Quote:
 4. Should I catch memory / third-party-library exceptions, handle them correctly and re-throw it? Or catch them and then throw my own exception class instead?
It doesn't matter who throws it. If an exception can be handled, and cause of exception fixed, then code should do so when it can, otherwise pass the exception to propagate upwards.

Quote:
 5. There's a difference between logging, warnings, fixable errors (like, when input is incorrect it could take a default sometimes) or regular errors. Which are best to be thrown?
Those that are exceptions.

Quote:
 I generally feel like exceptions produce quite a bit of bloat in the executable.
Yes. If only we had more than 1TB drives and more than 4GB of RAM.

Quote:
 In debug mode we want to debug and thus good error reporting. In release I suppose only critical errors are relevant...
This has nothing to do with exceptions. They are not error reporting tool, they are flow control. In some cases, an exception will be handled by logging the exception message.

And exceptions are not logs. They don't have different levels of severity. When an exception is throw, it indicates that catastrophic error has occurred, so bad, that there was simply no possible way for code to continue executing.

Share on other sites
Quote:
Original post by Bregma
Quote:
 3. What to do when in debug build there's more throws then in release mode? Or is this a malformed design? Like when a function does throw in debug mode, but doesn't in release mode. How would you define the function prototype? Dependent on whether its debug/release?

This should not occur. Either you can handle an exception or you can't.

Should not occur as in: there shouldn't be a difference between debug/release mode in what is thrown (this can make sense if it's only used for exceptional cases)? Or as in the function prototype definition, which is a non-issue when not using throw()-specifiers (which I don't plan to implement, after reading your and others their advice).

EDIT: Antheus clarified this: no difference between debug / release.

Quote:
Original post by Bregma
Quote:
 5. There's a difference between logging, warnings, fixable errors (like, when input is incorrect it could take a default sometimes) or regular errors. Which are best to be thrown? For debug? For release? Where do you make a distinction, or do you also use a second method for error reporting then exceptions?

Use exceptions only for exceptional circumstances. Input errors are not exceptional, they are expected.

Sounds good. How would you handle expected errors then? What if someone passes raw pixels + width + height to a function, and for some reason the width / height is zero. How would you inform the caller that the input is wrong?

Quote:
 Original post by AntheusAnd exceptions are not logs. They don't have different levels of severity. When an exception is throw, it indicates that catastrophic error has occurred, so bad, that there was simply no possible way for code to continue executing.

I see, I used it way too much then all the time.

Thanks both.

Share on other sites
Quote:
 What to do when in debug build there's more throws then in release mode? Or is this a malformed design? Like when a function does throw in debug mode, but doesn't in release mode. How would you define the function prototype?
I only do this in code that is designed to not use exceptions at all -- I still use them in debug builds for assertion failures, which usually get thrown all the way back to main (or to a unit test handler).
It could be a hint of a malformed design...
It shouldn't affect the prototype though, because as mentioned in other posts, exception specifiers aren't a good idea anyway.
Quote:
 5. There's a difference between logging, warnings, fixable errors (like, when input is incorrect it could take a default sometimes) or regular errors. Which are best to be thrown?
Logging, warnings and fixable errors definitely aren't good cases for exceptions. Errors that stop you from continuing are a maybe. In a game, there's not that many cases that should stop you from continuing though -- you should try to make as many of your errors "fixable" or "tolerable" as possible.
Quote:
 Exceptions do not add bloat and they do not affect the nonexceptional execution path in any meaningful way. Applications that use exceptions correctly tend to be larger than those that do not handle errors at all, which is the usual comparison.
Unfortunately enabling exceptions does generate extra code - for all the stack-unwinding that wouldn't otherwise need to be there.
This isn't usually a problem (especially on the PC), but if you're targeting hardware with a tiny cache (or you have other space restrictions), then this can actually be a problem and you might want manual control of where the exit points of a function are instead of having the compiler insert them all over the place.
e.g. The Wii has 0.25MB of L2 Cache, the 360 has 2MB and some Core 2 Duos have 6MB. So, yeah, on your PC - probably not a problem.
Quote:
 Original post by DecriusHow would you handle expected errors then? What if someone passes raw pixels + width + height to a function, and for some reason the width / height is zero. How would you inform the caller that the input is wrong?
If that situation can occur from someone feeding bad data into your program, then you should probably just return an error code (e.g. "This function will return NULL if the parameters fail the pre-conditions"), and then have the calling code check for failure (and perhaps log the error and continue).

Share on other sites
In addition to the memory issues, it's worth mentioning that most console platforms simply don't allow you to use exceptions, period. The vendors either strongly suggest you don't (because the compilers aren't optimized to deal with them), or they ship compilers that don't support them at all.

Share on other sites
Quote:
 Original post by Decrius4. Should I catch memory / third-party-library exceptions, handle them correctly and re-throw it? Or catch them and then throw my own exception class instead?

Just to add some extra stuff to this one.

Exceptions are part of an interface, even if throw specifiers aren't present (and it's generally accepted that they shouldn't be as others have noted). So it can be a good idea to document the exceptions that can be thrown by various parts of your code, even if it's just to say "all standard library and foolib exceptions may be thrown by this function".

So if you're creating a library or subsystem that uses another library internally, you might consider catching all exceptions thrown by that inner library and converting them to your own class(es) of exception.

If you don't do this, then you're exposing an implementation detail of your subsystem. Often this exposure isn't a big deal, but it's something to keep in mind if your writing what you hope will be a long-standing interface.

For example, if you write a class use the Xerces XML library to read a Collada file, should the user expect to have to catch exceptions defined by Xerces? Perhaps you'll change your XML library to RapidXML or something in future...

But in general, you should only catch exceptions if you can handle them in a useful way, or if you need to release resources in the case of an exception being thrown e.g.

thing *tp = new thing(x,y,z);try {     something_that_may_thrown(); }catch (...) {    delete tp;    throw;}

A dumb example, but this is probably one of the few valid uses for "catch(...)", IMO. However, if you find yourself writing code like this, you could and probably should re-cast your code in such a way as to use RAII:

thing t(x,y,z); // morally equivalent to all of the above!

EDIT: and one final point on this. If you expect to be able to recover meaningfully from exceptions at various points in your application, you should make sure you write your code in an exception-safe way. This takes practice, patience and discipline but the code one ends up with is often much cleaner (anecdotally).

The RAII mechanism of C++ actually makes this a lot easier to do than in many other languages as you don't need IDisposable/using (C#), "with" statements (Python), or boilerplate "finally" blocks (many others). Though RAII won't solve all possible exception safety issues, it will at least prevent leaks.

Share on other sites
Thanks the_edd. It sounds consistent to re-throw my own exception yeah. I also thought of a comment behind the prototype to document which exception might occur, good idea!

Also, for validating user / programmer input to a function; an alternative to Hodgman's return code method, would it be a good idea to do an assert on user input?

I read that asserts should be used for expressions that are always true to your believes (but sometimes turn out to be false -> useful debug information). How well would it be to use asserts for user-input validation?

Share on other sites
Quote:
 Original post by DecriusAlso, for validating user / programmer input to a function; an alternative to Hodgman's return code method, would it be a good idea to do an assert on user input?

IMO, it would be a bad idea.

Quote:
 I read that asserts should be used for expressions that are always true to your believes (but sometimes turn out to be false -> useful debug information).

Yes.

Quote:
 How well would it be to use asserts for user-input validation?

Not well at all. Rule of thumb: asserts are for implementers, exceptions are for clients.

If an assert fails, your program will be aborted, it will not pass Go, it will not collect £200. On unexpected/inadequate user input, you presumably don't want that to happen. Instead return an error code or throw an exception and when the time is right, display a useful error message.

And of course, the assert macro provided with the C and C++ standard library is effectively removed at the pre-processing stage when the NDEBUG macro is defined.

Aside: some people create their own assert macros that allow execution to continue after reporting an error. Personally, I don't like that idea as it doesn't gel with the original idea behind an assertion. I would call such a macro "hope" rather than "assert".

Share on other sites
Quote:
 Original post by DecriusThanks the_edd. It sounds consistent to re-throw my own exception yeah. I also thought of a comment behind the prototype to document which exception might occur, good idea!

There are a lot of problems with coding Java in C++. Java does not allow you to pass function pointers. Java requires throw specifications. C++ allows function pointers and does not implement Java-style throw specifications. As long as you write simple code, you can catch all contained exceotions and rethrow your own, but if you're providing any sort of customizable code (callbacks, delegates) you can not guarantee what code you call can throw. That means you're going to have to catch(...) and throw some sort of generic exception, just so you can act like Java.

If you never write code for others to extend, this is not a concern.
Quote:
 Also, for validating user / programmer input to a function; an alternative to Hodgman's return code method, would it be a good idea to do an assert on user input?I read that asserts should be used for expressions that are always true to your believes (but sometimes turn out to be false -> useful debug information). How well would it be to use asserts for user-input validation?

I have dealt with widely-available libraries (eg. OpenLDAP) that throw asserts in production code. I have cursed the authors of such code and their descendants to the seventh generation to eternal damnation in an inner circle of hell. Do not repeat their mistakes.