警报处理器

        警报处理器是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 打印输出能证明这一点。

 在实践中，我们会确保错误日志大到足够支持几天或几周的运作。每隔几天（或几周）就会 检查错误日志并调查所有错误。