I've got one for this group ... in a Map/Reduce, I'd like to

throw

an error in the map stage, so that I can process that error in the summary stage. I'd like to include to 'information' in the error for a better reporting experience in the summary stage. However, all I'm able to observe in the mapSummary.errors

"{"type":"error.SuiteScriptError","name":"UNEXPECTED_ERROR","message":"Unexpected Error"}"

No matter if I throw a error.create(), or a new Error(). Anyone here have success throwing data-rich errors in a map/reduce?

I use a custom error module that writes to a custom error record and puts all the info i need on there, script info, record info, anything else i want/need

Ok, you must not do high volumes then? The number of those records could be gigantic after a while no?

well I try to write my code in such a way that errors are rare 😛

lol. That's a fair comment

i write suiteapps now so this is only implemented for the suiteapps we install in an account, its not account wide

I can't explain why you would only see the unexpected error regardless of what you throw. However, regarding data-rich errors, you can provide any data you like to

error.create

as additional parameters. The extra data will be accessible under the

cause

property of the resulting

Error

instance:

are you sure the code is actually getting to the catch

@erictgrubaugh,always has his cape on. I've refactored my code to use your pattern. It error data flows nicely through to the summary stage. Thanks again.

@erictgrubaugh I always just put the data in the

message

parameter I didn't know you could add other parameters that get stuffed into

cause

. I don't see that documented is it uniform across all script types and what is the benefit over utilizing

message

? https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_158049399342.html

I can't confirm whether it is uniform, but I found this out when I was exploring the source of the

error.create

method on the client side. I'd be a little surprised if this implementation varied across script types, but it could. The benefit is that

message

is a

string

while

cause

is an

object

. You don't have to serialize then de-serialize your data using

cause

, but you do using

message

.