警报处理器是OTPgen_event行为的回调模块,它的代码如下:
-module(my_alarm_handler).
-author("ydq").
-export([init/1, handle_event/2, handle_call/2, handle_info/2, code_change/3, terminate/2]).
init(Args) ->
io:format("*** my_alarm_hander init:~p~n", [Args]),
{ok, 0}.
handle_event({set_alarm, tooHot}, N) ->
error_logger:error_msg("*** Tell the Enginner to turn on the fan~n"),
{ok, N};
handle_event({clear_alarm, tooHot}, N) ->
error_logger:error_msg("*** Danger over, Turn off the fan~n"),
{ok, N};
handle_event(Event, N) ->
io:format("*** unmatched event: ~p~n", [Event]),
{ok,N}.
handle_call(_Request, N) -> Reply = N, {ok, Reply, N}.
handle_info(_Info, N) -> {ok, N}.
terminate(_Reason, _N) -> ok.
code_change(_OldVsn, State, _Extra) -> {ok, State}.
这段代码和gen_server回调代码很相似。其中值得注意的方法是 handle_event(Event, State),它应当返回{ok, NewState}。Event是一个{EventType, Event-Arg}形式的元组,其中EventType是set_event或clear_event,而EventArg是一个用户提供的参数。
刚才发生了以下这些事情。 (1) 用-boot start_sasl启动了Erlang。这么做就得到了一个标准警报处理器。当我们设置 或清除警报时,什么事都不会发生。这就类似于之前讨论过的“什么都不干”的事件处理器。 (2) 设置警报(第1行)后只得到了一个信息报告。这个警报没有得到特别处理。 (3) 安装了一个自定义警报处理器(第2行)。my_alarm_handler的参数(xyz)没什么特殊 含义,只不过语法要求这里有一个值。但因为我们没有用值而是用了原子xyz,所以能在参数打 印出来时识别它。 ** my_alarm_handler_init: ...这段打印输出来自我们的回调模块。 (4) 设置并清除了一个tooHot警报(第3和第4行)。自定义警报处理器对其进行了处理,shell 打印输出能证明这一点。
在实践中,我们会确保错误日志大到足够支持几天或几周的运作。每隔几天(或几周)就会 检查错误日志并调查所有错误。