Skip to content

Error Handling

Jump to bottom
Jonathan Daugherty edited this page Mar 12, 2018 · 6 revisions

Currently, any errors received (usually from the Mattermost server, but also from other asynchronous things like opening the browser) are displayed in the current channel. This has several undesirable elements:

  • The user may no longer be in the channel associated with the message receiving the error, so the message is shown in a misleading location
  • The user may no longer be registered to that channel, so the errors (usually permissions errors) are inconsequential and should probably be suppressed
  • Information displayed with the errors is minimal (usually just a show of the error, but no indication of what request it was associated with or other context).
  • Error information may be scattered around in various channels and must be hunted down to be re-viewed.
  • Errors displayed using show are not pretty. Example for invalid hostname on login (see https://github.com/matterhorn-chat/matterhorn/issues/358): Error: Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [AI_ADDRCONFIG], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 6, addrAddress = <assumed to be undefined>, addrCanonName = <assumed to be undefined>}, host name: Just "mattermost.org.com", service name: Just "443"): does not exit (nodename nor servname provided, or not known)"
  • Errors as a result of searching are not displayed until the search box is dismissed, and then they are displayed in the channel (to reproduce, enter "/search" with no arguments).
  • Use reporting of errors could be assisted by the application, such as by a command or keybinding to dump errors to a file.

Consider how to enhance error handling, including potential concepts like:

  • Reporting errors in the channel they came from. Generally speaking we need to preserve provenance/context to errors so we can report that context to the user.
  • Reporting errors in a special (dismissable/re-viewable) window instead of as channel messages
  • Ability to suppress errors (may require more information or handler projection into common async elements)
  • Provide more enhanced information related to an error to allow better diagnostics capabilities.

Decisions

We decided on improving our internal error representation and decoupling presentation from other concerns. Relevant tickets are:

We'll look at presentation/reporting of errors in the user interface once we have addressed the above tickets. We also want to look at how the ring buffer of internal events relates to logging infrastructure.

Clone this wiki locally