Page Comparison

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.

...

The syntax of an explicit error statement is as follows:

error <level> <expr>

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. 

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:

fired {
  error info "query:"+query
}

The following would only raise the event if the query variable were empty:

fired {
  error info "Empty query" if(query like "^$")
}

...

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 service:

rule process_error {
  select when system error
  pre{
    genus = event:attr("genus");
    species = event:attr("species");
  }
  es:send_error("(#{genus}:#{species}) " + event:attr("msg"))
    with rule_name = event:attr("rule_name")
     and rid = event:attr("rid");
}

...

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:

meta {
  errors to a16x88
}

...