Prevent 'rolling' exception errors in the console

[vorg]

Whenever i get exception in my draw function it is caught and displayed in the console. But because there is no more drawing code executed they are printed @ 30fps which is annoying and unreadable. Because it's already cought by Plask I can't catch using process.on('uncaughtException', ...). Can we have something like this in redraw() ?

var prevException = null;

...

if (prevException != '' + ex) { prevException = '' + ex; sys.error('Exception caught in simpleWindow draw:\n' + ex + '\n' + ex.stack); }

[notlion]

Or we could simply not catch exceptions in redraw and leave that to the user. This would just cause plask to quit which is generally what you'd want, right?

[vorg]

I'm not sure if i want it to quit. What could be even better is to have error function along init, draw, so I can overwrite it if needed..

[notlion]

My preference would be for Plask to do as little as possible. If I don't want it to quit, I can just surround the code that might throw an exception with a try / catch and handle it there. But then, maybe I shouldn't be using SimpleWindow?

[deanm]

In the last few projects I've been working on, I've had a debug command line flag, and if it's enabled then I do extra OpenGL checking and other sort of asserts. Was thinking maybe it makes sense to have a simpleWindow flag like debug, where it will catch exceptions in init() and not call draw(), or it will just abort on exception in general. Then of course you wouldn't run this for an actual installation, but at least while you're working it helps a lot with the rolling exception thing which is really always a problem for me, at least.

[vorg]

I like the idea of debug flag causing application abort on exception. Would you also wrap gl object into error checks under the same flag?

On Thu, Aug 7, 2014 at 2:45 PM, Dean McNamee [email protected] wrote:

In the last few projects I've been working on, I've had a debug command line flag, and if it's enabled then I do extra OpenGL checking and other sort of asserts. Was thinking maybe it makes sense to have a simpleWindow flag like debug, where it will catch exceptions in init() and not call draw(), or it will just abort on exception in general. Then of course you wouldn't run this for an actual installation, but at least while you're working it helps a lot with the rolling exception thing which is really always a problem for me, at least.

— Reply to this email directly or view it on GitHub https://github.com/deanm/plask/issues/21#issuecomment-51466197.

Marcin Ignac http://marcinignac.com @marcinignac

[deanm]

I thought about that, but there are some problems wrapping the gl object, because now there are some APIs that expect the "real" gl object, not a wrapped one. The alternative for these APIs is like what I did for Syphon, which is the "factory" is on the gl function, so you call gl.createSyphonServer, instead of new SyphonServer(gl)...

I guess a simpler thing you could do is just check for gl errors at the end of a frame, but then you don't know exactly which API cause it, so it's not that helpful...

[vorg]

some APIs that expect the "real" gl object

What's the difference? Are they messing up with gl member functions themselves?

On Thu, Aug 7, 2014 at 8:05 PM, Dean McNamee [email protected] wrote:

I thought about that, but there are some problems wrapping the gl object, because now there are some APIs that expect the "real" gl object, not a wrapped one. The alternative for these APIs is like what I did for Syphon, which is the "factory" is on the gl function, so you call gl.createSyphonServer, instead of new SyphonServer(gl)...

I guess a simpler thing you could do is just check for gl errors at the end of a frame, but then you don't know exactly which API cause it, so it's not that helpful...

— Reply to this email directly or view it on GitHub https://github.com/deanm/plask/issues/21#issuecomment-51509016.

Marcin Ignac http://marcinignac.com @marcinignac

[deanm]

The difference is that they are native APIs, and they need to get the real NSOpenGLContext pointer underneath the JavaScript object.

[vorg]

Sure but instead of

var gl = { };
var val = ctx[key];
gl[key] = (function(key, val) {
  //debug stuff
})(key, val);

can we do

var val = ctx[key];
ctx[key] = (function(key, val) {
  //debug stuff
})(key, val);

and just use ctx (original gl) as usual?

[deanm]

I guess, but my idea was sort of not to "destroy" the original object.

[vorg]

I understand that as it's not a good practice. Maybe that should be another issue threat then. Let's then add 'debug' mode for now that exists on exception?

On Mon, Aug 11, 2014 at 1:03 PM, Dean McNamee [email protected] wrote:

I guess, but my idea was sort of not to "destroy" the original object.

— Reply to this email directly or view it on GitHub https://github.com/deanm/plask/issues/21#issuecomment-51771396.

Marcin Ignac http://marcinignac.com @marcinignac