WebGL exceptionSupport & performance

Continued from this thread, sort of.

We're having a bit of trouble here building without the WebGL exception support (WebGL player settings with exception support set to 'None').

We need the extra performance that would get us, but the build errors in the browser at load. Without exception support, we can't actually debug what's wrong. However, when switching ON exception support to find the cause of the error, the build actually runs fine: no errors! So we're stabbing in the dark.

I think it might have to do with the Emscripten try-catch injection that exception support enables. A few questions:

1. Where and how are the try-catch blocks injected? Around every C#/C++ function/method?
2. How much do they affect performance? It was mentioned blocks like that can't be as well optimized for asm.
3. With exception support OFF, do try-catch blocks we have in our C# code still function?
4. Do those C# try-catch blocks interfere with the Emscripten-injected try-catch blocks?
5. Does the loss of (asm) performance also apply to the C# try-catch blocks?

I understand these are fairly Emscripten-biased questions, but with IL2CPP in the mix I thought I might ask it here.

Any other advice to solve our catch 22?

 

Thanks for the hint, Jonas, quite helpful, should be in the build settings.

I found it easier to extend the script on the fly, by editing the index.html and adding this


// **************** insert stacktrace printing:
var p = code.indexOf('___cxa_throw(ptr, type, destructor) {');
if (p != -1)
{
code = code.substring(0, p + 37) + "console.log(stackTrace());" + code.substring(p + 37);
console.log('Successfully extended cxa_throw.');
}
else
console.log('Could not extend cxa_throw.');
// *****************


directly under the line

var code = codeXHR.responseText;


In order for this to work, one must also disable the direct script block insertion above that, by adding a "false &&" to the condition:

if (false && !(!Math.fround)) {


This also works in the non-development build, of course the function names are of no help.
The non-dev JS is minified, so the string to search for is '___cxa_throw(ptr,type,destructor){' and the two 37s must be 34s.

PS: The cxa_throw can be used to exclude certain types of non-fatal errors, or ignore them altogether (just adding a "return;" does the trick).

 

Really? Didn't see that, I'm building using 5.0.1f1, all I get is some disturbing message about exception handling being disabled (and the stacktrace cannot really be helpful with minimized function names).
Anyhow, I'm currently happy having discovered that I can completely catch all exceptions and rigorously ignore them instead of having the player crash with a message box (I'm having some dynamic gui code and sometimes there are GUILayout errors which have no real effect and can be ignored).

Update: Oh, you are talking about the future 5.1, not the just released revision. Great.
How about including (in the build settings) a list of exception types to ignore (or better a text to match, or a source function). Crashing the player is never a good option, errors aren't ever so fatal (all other unity platforms don't crash).

 

Seems counter-intuitive

If i disable exceptions, why would it print the stack traces.. ?

 

When then will we see 5.1

 

Now.. we have Unity 5.3.5xxx - are exceptions work? Or mayby Application.logMessageReceived ?