Skip to content
This repository has been archived by the owner on May 22, 2023. It is now read-only.

Latest commit

 

History

History
29 lines (20 loc) · 2.03 KB

errors.md

File metadata and controls

29 lines (20 loc) · 2.03 KB

« return to the patterns overview

Error Handling Patterns

Any LaxarJS widget or activity that communicates with the outside world can experience an error condition. This can be a an HTTP server that is not reachable anymore, failing to open a WebSocket connection, or an unexpected privilege restriction imposed by the web browser.

The didEncounterError Event

Widgets may use the didEncounterError event to inform about problems from which they cannot recover. This allows for some other dedicated widget or activity to take an appropriate measure, for example by displaying a message to the user or by informing a REST service dedicated to monitoring or logging. No topic configuration is needed for this event, as it is assumed that only a small number of activities or widgets are responsible for handling all types of errors.

The didEncounterError event is not intended to handle programming errors, such as null-pointer errors, which should be eliminated during testing. Also, it is not intended to inform about invalid user input: Have a look at resource validation events instead.

Event name Payload Attribute Type Description
didEncounterError.{code} published by any widget to indicate an unrecoverable error
code string HTTP_GET or HTTP_PUT (if applicable)
message string a more precise description of the problem
data object additional details, specific to the problem

The code values stand representative for any read and write, or (I/O) problems. If necessary, a sub-topic can be added, for example HTTP_PUT-WEB_SOCKET.

The message and data attributes should contain additional information.