Managed Errors in Morphir

Problem Statement

Error handling is difficult. Imperative languages tend to solve it by throwing and catching exceptions. Functional programming languages usually take a more explicit approach where error cases are captured in the type system and the developer is forced to handle them. Both of those approaches have pros and cons. Let's see how they compare from a business user's perspective:

As a business user, ...	So that ...	Imperative Answer	Functional Answer
I want to know when an error happened	I know that some corrective action needs to be taken	✓ throw exception	✓ return with error state
I want to know exactly where in the business logic the error happened	I know how to follow up	✓ stack trace	? composite error type
I don't want to deal with the possibility of errors when I build or review the business logic	I can focus on the important parts	✓	✗

As you can see the imperative approach is more in-line with what a business user wants in terms of behavior. At the same time, stack traces and exceptions are ok for developers, but business users need something more friendly. Also, the computational model of imperative and functional programming are fundamentally different so we cannot use the imperative approach for Morphir without changes.

Scaling Imperative error handling to Functional code

TODO