I’m starting a new topic to simplify things. Here is your last reply on old topic:
Hi Ron,
The issue with Unknown error is what the function is returning, please change the following line:
return five.createError("Insert failed: " + (queryResult.errorMessage ? queryResult.errorMessage() : “Unknown error”));
To the following:
return five.createError(queryResult, “Insert failed record”);
Passing the queryResult as the first parameter to five.createError allows five to wrap the existing error, and you should get its error message back in the front end, or if you want to include the error message, it is actually just called “Message”, so you can do the following as well :
return five.createError("Insert failed: " + queryResult.Message);
Could I please ask, when you start a new topic could you please start a new thread, it makes it easier for us to follow, as this question does not relate to the title, thanks in advance this would be very helpful to us.
Kind regards,
Jo
The server function has evolved since it was originally posted. Please advise the pros and cons of the 2 examples you provided for returning the error, and please also advise how the calling client-side function should handle each one.
Thanks so much…
Hi Ron,
The recommended way is the chaining method, this allows Five to chain errors that are returned from multiple functions. Returning this error as shown, Five will display an error message notifying what actually went wrong, the one thing you should do in the callback function passed into the executeFunction() is check if the error code returned from the backend is ErrErrorOk, please see example,
executeFunction() | Five | Low-Code For Real Developers
executeFunction() | Five | Low-Code For Real Developers
The first link will give you a description and the second link contains an example.
If it is not set to this, simply do not proceed any further as Five will display the error message automatically. However, if you were to ignore the errorCode on the serverResponse object, you can still do any other types of processing, but would recommend not using showMessage(), otherwise this will override the error message being displayed by Five (unless you want to show your own message, and hide the automatic message from Five).
If you want to further customize the error message being sent back, this is where you could extract the error message from the queryResults.Message, and create your error message to be displayed, so in effect, either way works, it just depends on what you would prefer.
Kind regards,
Jo
Thanks for the quick reply Jo-Anne. I am a bit confused. Your reply says to check for an error ode of ErrErrorOk, but the example (I presume example 2 is pertinent) shows:
function SaveDeliveryDetails(five: Five, context: any, result: FiveError) : FiveError {
const updateResult = five.executeQuery('Update Delivery Set Day=? WHERE DeliveryKey = ?', 0, five.field.DeliveryDay, five.field.DeliveryKey);
if (updateResult.isOk() === false) {
return five.createError(updateResult, 'Failed to save delivery details');
}
return five.success(result);
}
In the example it’s using the updateResult.isOk, which I guess is different from ErrErrorOk.
I know this is complex, and I want to make sure I’m using the correct property. Is there a difference between using these 2 properties?
I presume I’m using this method in the server function (from my earlier message on this thread):
Thanks for the previous replies, but I really need these answers. I can’t continue development on my project if I’m stuck on how to do this. Please help…
Hi Ron,
Try changing the code to return the error as follows, this won’t chain the error message, but will create the error message as ‘Insert failed : reason will appear here’:
return five.createError("Insert failed: " + queryResult.Message);
The isOk() functions that are returned in the API are a shortcut to know if you have an error, or everything is ok, if you get an error then you can deal with the type of error returned inspecting the message.
In regards to the ‘ErrErrorOk’ error code returned from the server, this is the raw response as JSON and has not been parsed into an error object yet, hence why you can simply check for this string representation, in the future we may wrap this so you can use isOk(), but this is pretty much the only edge case where you need to inspect the raw value instead.
As some helping ways to inspect the error returned from an API call, try logging to five.log a JSON representation, this will allow you to see the contents of the error object in the inspector, please see screen shot for example :
eg
five.log(JSON.stringify(updateResult));
Kind regards,
Jo
Thanks so much for clearing this up, Jo. It explains a lot.
You gave me a way to get just one error without chaining the errors, but why? Isn’t chaining the errors the proper / default way?
It’s not that I did not want them chained, I just didn’t know how to handle what came back. Please advise the more proper way to handle errors, and maybe an example of a chained error JSON object so I will know how to do this correctly.
Again, thanks for replying, I really appreciate it!
Hi Ron,
You can use either way when returning errors, chaining just makes it easier if you are several levels in nested code, and can return additional information all the way back to the top original calling function, example of this is as follows:
const reportResult = five.executeAction(‘StaffExtensssssion’, {});
const chainedError = five.createError(reportResult, ‘Chained error 1’);
const chainedError2 = five.createError(chainedError, ‘Chained error 2’);
five.log(JSON.stringify(chainedError));
See screen shot for what is returned and displayed in the inspector. Note: the action ID is meant to be incorrect as this causes the error to be returned in the screen shot.
So, to sum up, you can choose, depending on what’s your preference, you can send a single error all the way back, or chain it, you choose.
Kind regards,
Jo
