MuleSoft Error Handling — Quick and Dirty Learning
Very frequently I resort to quick and dirty learning short-cuts. One reason I avoid, whenever possible, reinventing the wheel and second, more importantly, these short-cuts provide me with a starting point for diving deep. For my MuleSoft Certified Developer test, which I cleared this year, I prepared a few such learning short-cuts which I thought may be helpful for some others like me.
This part talks about my flow chart for exception handling. MuleSoft has only two possibilities while handling an exception —
On Error Propagate (OEP) — Payload is populated by error message by thrown exception.
On Error Continue (OEC) — Payload is populated by payload message specified by developer.
Keeping this in mind here it goes (divided into three parts to maintain visual clarity)-
So three possibilities here — your exception is raised in a “Try Block” (Path B), or in a “child flow” (Path C) or within the main flow.
As you may have noticed that both “Try Block” and “Child Flow” may re-raise the exception in the main flow (Path A).
The main idea in understanding the exception flow is breaking down the flow till you reach the main flow. Decision on final message and status can then be determined by On Error Propagate (OEP) or On Error Continue (OEC) payloads.
Disclaimer — Is this quick and dirty method good? No. A thorough understanding of official document is always preferable. But short-cuts do help.
