All server scripts - when faced with an DBError - abort - rather than allowing the user to trap for the Error condition (which should be allowed).....
Consider the following Code from a Server script:
function fMassChange(databaseId, collectionName, sWhere, oUpdate, sMasterKey) {
var bReturn = false;
try {
console.log('[JS-INFO] fMassChange running Update in Table: ', collectionName, ' Where Clause ', sWhere, ' Update JSON: ', oUpdate, ' MasterKey: ', sMasterKey);
var oMassUpdate = Collection.multiUpdateObject(databaseId, collectionName, sWhere, oUpdate, null, sMasterKey);
// var result = Collection.multiUpdateObject(databaseId, collectionName, '{"bScannedForDupes": true }', {
// "bScannedForDupes": false, "bIsDupe" : null , "bIsUniqueRow" : null
// }, null, sMasterKey);
Code: Select all
console.log('[JS-INFO] fMassChange Complete - Result:', oMassUpdate);
bReturn = true;
} catch (e) {
bReturn = false;
console.warn('[JS-ERROR] running fMassChange: ', e, ' Action Was in Log Record Immediately Prior.... ');
}
return bReturn; }
When this function is called in the server script like this:
try {....lots of other logic above this.....
//
// Change the OnBoarding Tasks to a blank mentor ID
//
collectionName = 'OnBoardingTasks';
var oMyUpdate = {
"sMentorID": null
};
var sWhere = '{"sOnBoardingEventsID": ' + oEvent[0]._id + ' } ';
fMassChange(dbId, collectionName, sWhere, oMyUpdate, sMasterKey);
} catch (e) {
console.log('there was a Fetal error during action: ', sAction, ' Error Message: ', e.message, ' Error ncode was:', e.code);
responseBody.actionTaken = "Error" + ' during ' + sAction;
responseBody.result = "Error"
responseBody.error = "Fetal Error During Execution - Execution Halted - Error Message: " + e.message + "ncode: " + e.code;
response.error(responseBody, 500);
}
//==========================================================
So - there's a syntax error in the string based where clause required by the multiUpdateObject in the above call.
The expected behavior is that - inside the function call - the code 'fails out' to the catch(e) statement inside the function call. However, it does not - and it fails out to the OUTER catch(e) statement - which abruptly terminates the script - unexpectedly.
This type of result occurs whether or not the multiUpdateObject statement is in a function call - or part of the main script (I moved it to a function to isolate the behavior and debug the error).
This behavior happens in other database functions - and - is a recent behavior. For Example - when an Unique Index is violated by entering a duplicate key - I'd like to trap that behavior - because the error is sometimes 'desired' and results in another set of actions. Yet - it cannot be trapped and results in this error:
there was a Fetal error during action: [JS-INFO] Adding Record to table OnBoardingTasks :{"sTaskName":"Acccompany OnBoarder to Veterans Monthly meeting","sUserID":"5a9092ac0326853b6f214d5a","dDueDate":"2018-02-26T15:54:24.968Z","sTaskID":"59f0ef77f494ed09c0111e81","sAssignmentType":"MANAGER","sOnBoarderUID":"5a957f300326853b6f2209cf","sManagerID":"5a9092ac0326853b6f214d5a","bActive":true,"bComplete":false,"sColor":"#EE82EE","sTaskListID":"59f0ef77f494ed09c0111e8c","sUserName":"a href="mailto:bruce.stuart@amazingorg.com" rel="nofollow"bruce.stuart@amazingorg.com/a","sOrgID":"59f0ef76f494ed09c0111e66"} Error Message: Index does not allow fields with non-unique values Error ncode was: DBSC217
Again - the error is expected - the part that's NOT expected - is that the try / catch loop that was around the code to do the insertObject - is being bypassed - and the code errors out to the 'outer loop'.
I know there are workarounds, but the workaround is to write additional code to account for things that should be handle-able inside the catch(e) code. Most Appery users will NOT be able to do this.
Have you guys seen this problem before? do you need a compact script that illustrates the issue ? I have granted you access to my script if you'd like to view the code. Please advise if this issue can be fixed.
it is here: https://api.appery.io/rest/1/code/Peo...
Best,
Bruce
