Application errors are managed by the platform, but both application builders and users should be aware of how errors are handled.
Application errors are handled according to where the error occurs and the nature of the error. For instance, a column in a report may reference a deleted field or have a calculation that is invalid under specific conditions - e.g. a division by zero - and each of these situations are handled in different ways. If this same exception were to happen in a workflow it would necessarily be managed differently to how it was managed in the report.
Calculations
Calculation are a common source of errors because changing data can cause unexpected situations, so that the calculation may be valid for some data and yet cause errors with other data, such as the example of a division by a field that is sometimes zero.
Compilation Errors
In the case where the calculation contains an error such a typo on a function name, the error will be highlighted in the calculation editor but the calculation can still be saved. This is convenient so that the calculation can reference a field before the field is created, but if the field is never created then the calculation will have an error.
Run-time Errors
Run-time errors as usually caused by unexpected data. When certain data causes an error, the calculation result will be blank. This means that a report might have some rows where the value is blank.
Imagine a stock inventory report where there are columns for numbers of units, total value, and a unit value that is calculated by dividing the total value by the number of units. If the number of units is zero then the unit value column will be blank on those rows.
Schema Changes
Over time there will be changes to the definition of various objects and fields will be deleted. This will have an effect on the behaviour of the application.
Forms
Form Builder is the interface to edit objects, so changes to an object will immediately update the current form; where there are multiple forms for an object an error will appear when the form is opened.
Reports
Reports that were created before the deletion may still have these fields as columns in the report definition. When this happens, the report will run for users but the affected column will be missing because it cannot be resolved when the report runs. This will continue to happen until the the report definition is edited; when report builder is opened then a message appears saying that the affected columns will be deleted when the report definition is saved, thereby automatically resolving the problem.
Workflow Errors
An error in a workflow will result in the workflow ending with a failed state, even if only a single record causes the failure. An example is a Get Records loop, where an error on one record will cause the entire workflow to fail. The Workflow Runs page has a history of workflow execution and the state of each, where Completed indicates success and Failed denotes a failure.
Some workflow activities contain timeout routing, which is a method for the application builder to manage how expiry conditions are handled.