Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't allow body removal during step() #212

Closed
schteppe opened this issue Feb 13, 2016 · 4 comments
Closed

Don't allow body removal during step() #212

schteppe opened this issue Feb 13, 2016 · 4 comments

Comments

@schteppe
Copy link
Owner

From previous discussions (#207, #208), I've realized that it's too complicated to try to "fix" the problem of removing bodies during step(). Logically, one would need to fix adding of bodies as well, and applying the same solution for constraints as well. And all other things that can be changed in the World which aren't really compatible with step().

This is simply too much work and can simply be avoided by not doing those things during step() - just postpone it. Read more here: http://www.iforce2d.net/b2dtut/removing-bodies

I suggest throwing an error in the following methods, if they are used during the step.

  • World.prototype.addBody
  • World.prototype.removeBody
  • World.prototype.addConstraint
  • World.prototype.removeContraint

(just keeping this issue here to remind myself to implement this, and to get potential feedback)

@jtenner
Copy link

jtenner commented Feb 15, 2016

Please do now "throw" inside the function. This will cause a v8 deoptimization and really hinder performance.

Do this instead:

function privateFunctionThrower(msg) {
   throw new Error(msg);
}
//later in the code ...
if (errorState) {
   privateFunctionThrower('Message');
}

V8 doesn't like compiling functions that throw.

This is also a very good idea.

@schteppe
Copy link
Owner Author

Thanks!

I thought only try/catch statements were unoptimized in v8, not actually the throwing code? See https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#2-unsupported-syntax

If "code that might throw" was unoptimized, then all JS code would be unoptimized (for example, TypeError). Maybe I'm wrong.

@jtenner
Copy link

jtenner commented Feb 15, 2016

Why am I so quick when I'm wrong? Hah.

I remembered that try-catch statements were bad. My mistake.

Throw as you like.

@schteppe
Copy link
Owner Author

I don't blame you, I do exactly the same thing sometimes too.

Gonna throw my errors in the air, like I just don't care.

schteppe added a commit that referenced this issue Feb 20, 2016
…s during step. Also throw when in a bad constraint/body state #212 #207
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants