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