If you followed along, you know that KRL, kinetic language of the rule is an event in the language processing for the processing of events on behalf of an individual entity (usually a person). Think of it as a language of processing of complex events of the people.
For a long time, it has been difficult for developers KRL control errors. The language did not have any mechanism for exceptions and the only hope was to activate debug and fix them. However, all too often, you don't want to correct errors and handle them. Errors are not always problems in the code: errors to correct - but exceptional conditions that a program needs to be ready for and treat appropriately.
Most modern language have some kind of control mechanism of exceptions, some more sophisticated than others. I realized that control of exceptions is usually treated as a small system event within a larger imperative language. KRL, a language event, is perfectly suitable for error handling: If only the system would raise them as events. To date, it does.
The most recent update of the kinetic rules engine provides support in KRL for functions related to errors and mistakes in KRL control:
system errors - errors in the system (how to apply an operator to an operand of an inappropriate type so that the system cannot recover) will cause an event with system of domain events and errors of the type of event. The event may have the following attributes: msg - error message as a text stringlevel - error level, one error, warning, info, debuggenus - categorizing main error according to the hierarchy of events is shown in documentation.species - less categorization of the error with the hierarchy.rid of the event - ID of set of rules that caused the errorrule_name - the name of the rule that caused the errorexplicit errors - as we shall see below, developers can explicitly event cause- and -error. These errors event domain user and the type of event error can be msg, level, eliminating and rule_name attributes.
redirection of error - block target now supports the inclusion of the errors for pragma that defines the set of rules which is control of errors for the current set of rules.
target {... a16x88 version "dev" errors...}The release clause is optional.
Error handling - ErrorStack module admits errors in shipment to ErrorStack online service. Of course, other actions may also be taken as appropriate.
Cause error events is a natural way to treat out-of-bounds conditions in a set of rules KRL already rules to respond to errors in writing is a natural extension of the basic behavior of the system. When the system generates an error event, or a developer makes that one was raised with an explicit statement of error in the postlude of rule, that event is evaluated by the engine in the current implementation cycle and any rule that selects for that mistake with the given attributes, the type and the domain of event will be added to the programming of the evaluation.
The rules in the current set of rules for the selection will be assessed in the absence of errors for pragma in the block of the goal. If the errors to pragma, the rules in the RuleSet identified by this pragma will be the evaluation for the selection. If a set of rules has no rules to control the event of error and mistakes to pragma is not present, the event of error, like any other unhandled event, does not affect the implementation of the set of rules or system.
ErrorStack module is a simple example of how you can report bugs. ErrorStack is a service that provides an API to report errors that are presented to the owner of the error with the support of categorization stack, alerts and viewing. To register for the service of Error stack, you can create any number of batteries from various reports of errors. A developer key uniquely identifies the pile of errors that are reported, the errors.
ErrorStack module has a single definite action, send_error, that takes a message. When you use the module in a set of rules (by using pragma module) is configured with the key to stack the developer receives Error stack. The following code fragment shows a rule that handles errors and reports to an Error by the action of send_error stack:
process_error rule {select when system error or user error pre {genre = event:param("genus"); species = event:param("species");} e:send_error ("(#{genus}:#{species})" + event:param("msg")) with rule_name = event:param("rule_name") and remove = event:param("rid");}The rule assumes that the following pragma was present at the Bloc's goal of the set of rules and the developer key is stored in keychain from the set of rules:
use the a16x104 module alias is es_key = keys:errorstackError stack is not the only way to control errors. More generally, can use the HTTP library to send the notification to some other API such as notifio, the library of Twilio to send an SMS, or even tweet the error. Alternatively, there may be some mitigation to apply.
Developers can raise their own errors using the error in the postlude. Technically, an error is simply an event, developers have been able to do so using the explicit event and it may yet. Instruction error just more convenient. The syntax of an explicit statement of error is:
Each set of rules must be a rule of error control General as above or send errors to a set of rules that have been created to control errors. Of course, error control rules can be more specific mode with more sophisticated select statements, filtering in the genre of error and species, as well as the error message. Controller error that causes mistakes themselves do not cause an infinite recursion in any case the system you will catch you and break the chain of events.
Posted by windley may 24, 2011, 11: 59 AM
没有评论:
发表评论