In a client-side human service the scripts run in the browser, so errors are JavaScript exceptions in the coach page. Handle them at three levels:
1. In the CSHS diagram - a client-side script step and a nested service flow call can have an error boundary event: drag the error event onto the step, wire it to a coach that shows the message; the error event's error data mapping puts the error object into a variable you choose (e.g. tw.local.err: errorCode, errorMessage, errorText). Unhandled errors bubble to the CSHS's global error handler (Overview > "Error Handling") and finally to the portal's generic error page.
// client-side script step: throw so the error boundary catches it
if (!tw.local.order.customerId) throw new Error("Customer is missing"); // -> error boundary event -> "Show error" coach
// catch inside a script and continue
try { tw.local.summary = JSON.parse(tw.local.rawJson); } catch (e) { tw.local.summary = null; tw.local.warning = "Summary not available: " + e.message; }2. In coach views and control events - wrap risky code, and report through the UI Toolkit instead of the console:
// button on click
try {
var total = ${Lines}.getData().reduce(function (s, l) { return s + l.qty * l.price; }, 0);
${Total}.setData(total);
} catch (e) {
${Status}.setText("Cannot calculate the total: " + e.message); ${Status}.setColorStyle("D"); // Status Box / Alert control
console.error(e);
}3. Service flow errors - a service flow called from the CSHS that ends in an Error end event (or throws) returns the error to the CSHS as an error event on the call step; catch it there and show a coach; the same for a Service Call control in a coach: its on error event receives {errorCode, errorText, serviceInError}.
Diagnostics: a global window.onerror in a small coach view on every coach can log unexpected errors to a service (audit) instead of losing them; the browser console remains the first stop while developing.
References