Tuesday, 15 March 2011

javascript - Does using a "Try Catch" when adding new code to delivered code create a safety margin? -



javascript - Does using a "Try Catch" when adding new code to delivered code create a safety margin? -

this more of conceptual question specifically, programming (currently) javascript file contains massive amount of delivered code (ie vendor supports delivered code , not our customizations).

because essential delivered code always execute, method of encapsulating customized code try{} catch(e){} ensure if custom code fails, delivered code execute?

i encapsulate every bit of custom code. if utilize delivered variable, assign custom var , 1 line assignment encapsulated in try{} catch(e){}.

does method work? method overkill and/or how can improved?

here do:

//delivered code var global1 = true; var global2 = true; //my custom code try{ var custom_global3 = true; } catch(e){ console.error(e); } //more delivered code if(global1) dosomethingawesome(global2); //my custom code try{ makeitlessawesome(custom_global3); } catch(e){ console.error(e); }

this grab run-time errors, not syntax errors @ parse time (or "early errors" in ecmascript terms). example,

try { var foo = 1; } // oops.. } catch(e) { // never used }

here, there's bracket mismatch, parser can't figure our try ends , catch begins. it's not possible try-catch grab parse error, because error beingness caused by malformed try-catch before code runs.

another illustration of parse-time error invalid left-hand assignment, 4 = 5:

try { 4=5; } catch(e) { /* never used */ }

a perchance improve approach (depending on how code structured) place custom code in separate files or <script> tags. syntax error stop entire script file (or <script> section) running, if other code in totally different file/<script>, that's not problem.

finally, awful solution place of custom code within of strings in eval statements, , place eval statements try-catch blocks:

try { eval("4=5;") } catch(e) { console.log(e); // caught error... @ cost?? }

eval bad, in terms of performance, because you've stopped parse , run exclusively new script, whereas normal code outside of eval parsed on first pass of parser else. avoid solution if @ possible. (eval bad in terms of security, that's issue if dynamically build code strings, var v = "alert('reallybad')"; eval("var foo = " + v);. don't dynamically build code strings!)

javascript performance integration-testing robustness

No comments:

Post a Comment