Events are a natural way to handle errors. KRL makes use of its built in event system to process errors. Raising events for errors and then handling them with rule sets gives developers a great deal of flexibility in dealing with exceptional situations in their code.

...

• action
  • undefined
• data
  • conversion failed
  • source unavailable
• expression
  • invalid operator
  • type mismatch
  • recursion threshold exceeded
  • array reference undefined
  • function undefined
• module
  • function undefined
  • module undefined
• operator
  • type mismatch
• system
  • malformed event
  • ruleset_not_installed
  • unknown

Program-Raised Errors

In addition to system errors, KRL programs can also raise errors explicitly in the rule postlude. User-raised errors have the event domain system and the event type error. The genus is set to user.

...

In this statement, <level> is one of error, warn, info, or debug, and <expr> is any valid KRL expression that results in a string (or something that can be cast as a string, such as a number). The expression will be sent as an event attribute with name msg.  data.

If <level> is error, all rules added to the current execution schedule are removed, also preventing further execution of the rule that raised the error. This type of error can still be handled, as shown in the Handling Errors section below.

The following example would raise an event with domain system, type error, genus user, level info and a message with the value of a variable named query if the rule were to fire:

...

Handling errors is as easy as creating a rule with the right select statement. For example, the following rule will use the send_error() action from the errorstack module (aliased as es) to record an error using the Error Stack servicelog everything about the error:

rule process_error {
  select when system error
  pre{
    genuslevel = event:attr("genuslevel");
    speciesdata = event:attr("speciesdata");
  }   es:send_error("(#{genus}:#{species}) " + rid = event:attr("msgrid"))

   with rule_name = event:attr("rule_name")
     and ridgenus = event:attr("genus")
    info = {
      "level": level,
      "data": data,
      "source": rid+":"+rule_name,
      "genus": genus,
      "time");: time:now()
    }
  }
  always{
    log error info.encode()
  }
}

Like any other event, if an error event is raised and no rule is selected for it, nothing happens.

Because developers often want to process all errors from several rule sets in a consistent way, KRL provides a way of routing error events from one rule set to another. In the meta section of a rule set, developers can declare another rule set that is the designated error handler. For example, if the preceding process_error rule were defined inside rule set a16x88, then the following declaration would automatically route error events from the current rule set to a16x88 for processing:

...

...