I think your main problem is that you are swallowing exceptions that are very bad . That's why "sometimes it works." Something throws an exception, and you catch it, but then after that you do nothing. At least I would display some kind of error message in your catch .
A few other issues:
- Are you sure you need these few
try..catch blocks? The current assumption in your code is that every line enclosed in try..catch is independent of the others, and execution can continue if something goes wrong in any (or more) of these statements. Are you sure this is what you want? If so, definitely the best way to handle this. - If the statements are not independent of each other, and if a failure at any point means that the execution cannot continue, you can wrap all these statements in a single
try..catch block and display the error message in catch - As I said, swallowing exceptions is very bad ! You hide the problem and do nothing. It also makes debugging extremely difficult because everything will stop working and you won’t know why (without exception, without registration, error messages). Exceptions are used when something unexpected happens that interrupts the normal flow of a program. This is what you definitely want to handle.
I think you can do this:
try { if(window.opener.hideRecordReload){ window.opener.hideRecordReload(pg.recordID, pg.recordTypeID); } else { window.opener.pg.hideRecord(pg.recordID, pg.recordTypeID); } window.opener.pg.hideEncounter(pg.recordID); window.opener.pg.hideRecordResponse(pg.hideReasonID.value == 0 ? pg.otherReason.value : pg.hideReasonID.options[pg.hideReasonID.selectedIndex].text); window.opener.pg.hideRecord_Response(pg.recordID, pg.recordTypeID); window.opener.pg.hideRecord_Response(pg.recordID, pg.recordTypeID); window.opener.window.parent.frames[1].pg.loadQualityMeasureRequest(); window.opener.pg.closeWindow(); } catch(e) { console.log(e); }
Thus, if an exception occurs anywhere in these series of statements, the catch will handle it.
Javascript also does not have true checked-exceptions. You can get around it by having one try block and checking the exception object you get * .
Extending what I mentioned earlier, there are two ways to handle exceptions. The first method, as I showed earlier, assumes that when an exception occurs, the code is in an invalid / undefined state, and this means that the code has detected a fatal error. Another way to handle exceptions is if you know that this is something that you can recover. You can do this with a flag. So:
try { doSomething(); } catch(e) { error = true; } if(error) { doStuffToRecoverFromError(); } else { doOtherStuff(); }
In this case, your logic flow depends on the exception thrown. The important thing is that the exception can be restored, and depending on whether it was selected or not, you do different things.
* Here is a somewhat contrived example showing proven exceptions. I have two exceptions called VeryBadException and ReallyBadException that can be selected (randomly) from two functions. The catch handles the exception and calculates what type of exception it uses with the instanceof operator):
function VeryBadException(message) { this.message = message; } function ReallyBadException(message) { this.message = message; } function foo() { var r = Math.floor(Math.random() * 4); if(r == 2) { throw new VeryBadException("Something very bad happened!"); } } function bar() { var r = Math.floor(Math.random() * 4); if(r == 1) { throw new ReallyBadException("Something REALLY bad happened!"); } } try { foo(); bar(); } catch(e) { if(e instanceof VeryBadException) { console.log(e.message); } else if(e instanceof ReallyBadException) { console.log(e.message); } }
Vivin paliath
source share