[Erlang37]error/1 exit/1 exit/2 throw/1的区别。erlang应用脚本stop分析。

1. error/1

erlang应用脚本stop分析

实质上这首文章的名字应该是何等安全关闭erlang应用越来越科学。

一言九鼎是网就此来定义内部错误的: Erlang内建的run time error 一共有10种:

erlang应用脚本生成

利用rebar工具,创建一个erlang节点后,
<pre>
./rebar create-node nodeid=hook_heroes
</pre>
然后以rel目录里面,执行打包命令
<pre>
./rebar generate
</pre>
会面扭转完整的运包,目录如下:
<pre>
bin erts-6.0 lib log releases
</pre>
bin里面,有一个启动脚论名字与节点名字一样的,这里是hook_heroes

停下服务的时节,目前应用
<pre>
./hook_heroes stop
</pre>

function_clause/case_clause/if_clause/badmatch/badarg/undef/badarith/badfun/badarity/system_limit, 比如:         

对于hook_heroes stop分析

hook_heroes stop调用如下
<pre>
%%Tell nodetool to initiate a stop
$NODETOOL stop
ES=$?
if [ “$ES” -ne 0 ]; then
exit $ES
fi
</pre>
这里的nodetool来自
<pre>
NODETOOL=”$ERTS_PATH/escript $ERTS_PATH/nodetool
</pre>
纵使erts包下的nodetool脚本,传入的参数stop
nodetool是一个escript脚本,作用就是“Helper Script for interacting with
live nodes”

<pre>
case RestArgs of
[“getpid”] ->
io:format(“~p\n”,
[list_to_integer(rpc:call(TargetNode, os, getpid, []))]);
[“ping”] ->
io:format(“pong\n”);
[“stop”] ->
io:format(“~p\n”, [rpc:call(TargetNode, init, stop, [], 60000)]);
…….
</pre>

足见到,直接行使的是rpc:call()方法:调用TargetNode的init模块的stop方法,传入的参数为[],下面来探init模块的stop方法。

 1> erlang:binary_to_list(1).
    ** exception error: bad argument
       in function  binary_to_list/1
       called as binary_to_list(1)
init模块的stop()方法调用

init 模块的文档给的诠释是:“Coordination of System Startup”,
stop方法的注解是:
<pre>
All applications are taken down smoothly, all code is unloaded, and all
ports are closed before the system terminates
</pre>
众所周知就是用来系统关闭的,关键是待看他是怎么关闭系统的。

 这上面就触发了error/1,我们吧足以手动触发一下。

函数入口:

<pre>
stop() -> init ! {stop,stop}, ok.
</pre>
让init模块发送温馨发送一个{stop,stop}消息,

init自己循环接收信息
<pre>
loop(State) ->
receive
{‘EXIT’,Pid,Reason} ->
Kernel = State#state.kernel,
terminate(Pid,Kernel,Reason), %% If Pid is a Kernel pid, halt()!
loop(State);
{stop,Reason} ->
stop(Reason,State);
{From,fetch_loaded} -> %% The Loaded info is cleared in
Loaded = State#state.loaded, %% boot_loop but is handled here
From ! {init,Loaded}, %% anyway.
loop(State);
{From, {ensure_loaded, _}} ->
From ! {init, not_allowed},
loop(State);
Msg ->
loop(handle_msg(Msg,State))
end.
</pre>

配合到{stop,Reason},进入stop(Reason,State)这里调用,Reason为stop,
来起这里
<pre>
stop(Reason,State) ->
BootPid = State#state.bootpid,
{_,Progress} = State#state.status,
State1 = State#state{status = {stopping, Progress}},
clear_system(BootPid,State1),
do_stop(Reason,State1).
</pre>
最主要看下clear_system函数和do_stop函数

 2> erlang:error(badarg).    
    ** exception error: bad argument        
clear_system()函数

clear_system()这里的意向就是是关闭虚拟机中之经过,只所以三个函数调用
<pre>
clear_system(BootPid,State) ->
Heart = get_heart(State#state.kernel), %A
shutdown_pids(Heart,BootPid,State), %B
unload(Heart). %C
</pre>

A和C都是于处理erlang启动参数heart,其意思在vm.args有证
<pre>
Heartbeat management; auto-restarts VM if it dies or becomes
unresponsive
(Disabled by default..use with caution!)
-heart
</pre>
相似情况下,不采取-heart
咱俩这边仅拘留shutdown_pids()怎么开的。

只顾到erlang直接把badarg这种内建的error转成重详尽的bad argument,

shutdown_pids()函数

<pre>
shutdown_pids(Heart,BootPid,State) ->
Timer = shutdown_timer(State#state.flags),
catch shutdown(State#state.kernel,BootPid,Timer,State),
kill_all_pids(Heart), % Even the shutdown timer.
kill_all_ports(Heart),
flush_timout(Timer).
</pre>

此首先关闭定时器,然后倒闭kernel进程,然后又kill其余的经过。

关闭kernel进程
<pre>
%%
%% A kernel pid must handle the special case message
%% {‘EXIT’,Parent,Reason} and terminate upon it!
%%
shutdown_kernel_pid(Pid, BootPid, Timer, State) ->
Pid ! {‘EXIT’,BootPid,shutdown},
shutdown_loop(Pid, Timer, State, []).
</pre>

更进一步,我们也堪运用error/1定义自己之荒唐

什么是erlang的kernel进程?

立句话是最主要: A kernel pid must handle the special case message and
terminate upon it!
这就是说什么是kernel进程也?
看下bin/start.script
<pre>

{kernelProcess,heart,{heart,start,[]}},
{kernelProcess,error_logger,{error_logger,start_link,[]}},
{kernelProcess,application_controller,
{application_controller,start,
[{application,kernel,

</pre>

这些带kernelProcess标签的进程都是, 特别是application!

来自http://blog.yufeng.info/archives/1411

故supervisor_tree收到的凡{‘EXIT’,BootPid,shutdown}

kill其余的过程:
<pre>
kill_all_pids(Heart) ->
case get_pids(Heart) of
[] ->
ok;
Pids ->
kill_em(Pids),
kill_all_pids(Heart) % Continue until all are really killed.
end.
</pre>
最终和下去,使用的是
<pre>
exit(Pid,kill)
</pre>
通往各个进程发送kill消息。

3> erlang:error("this is my own error").
   ** exception error: "this is my own error"
supervisor terminate方法

supervisor中的terminate()方法如下:
<pre>
-spec terminate(term(), state()) -> ‘ok’.

terminate(_Reason, #state{children=[Child]} = State) when
?is_simple(State) ->
terminate_dynamic_children(Child,
dynamics_db(Child#child.restart_type,
State#state.dynamics),
State#state.name);
terminate(_Reason, State) ->
terminate_children(State#state.children, State#state.name).
</pre>

分为simple_one_for_one和非simple_one_for_one两种状况。
terminate_dynamic_children()方法:
<pre>

EStack = case Child#child.shutdown of
brutal_kill ->
?SETS:fold(fun(P, _) -> exit(P, kill) end, ok, Pids),
wait_dynamic_children(Child, Pids, Sz, undefined, EStack0);
infinity ->
?SETS:fold(fun(P, _) -> exit(P, shutdown) end, ok, Pids),
wait_dynamic_children(Child, Pids, Sz, undefined, EStack0);
Time ->
?SETS:fold(fun(P, _) -> exit(P, shutdown) end, ok, Pids),
TRef = erlang:start_timer(Time, self(), kill),
wait_dynamic_children(Child, Pids, Sz, TRef, EStack0)
end,

</pre>

足见到ChildSpec中的ShowDown字段的装置于关闭子进程的影响:
brutal_kill:发送kill消息,这个消息是休克捕捉的。即使要worker设置了process_flag(trap_exit,
true),仍然不会见吸纳{‘EXIT’,_FROM,REASON}这个消息;
infinity和Time都见面朝着监督的worker进程发送shutdown信号,这里worker做了
process_flag(trap_exit,
true),自然会收到{‘EXIT’,_FROM,REASON}。唯一的分别是infinity会一直等,Time会设置一个超时:如果超时了了,那么supervisor会发送kill信号,直接杀。
依据地方的解析,不难和erlang文档中对gen_server terminate()方法
<pre>
If the gen_server is part of a supervision tree and is ordered by its
supervisor to terminate, this function will be called with
Reason=shutdown if the following conditions apply:

the gen_server has been set to trap exit signals, and
the shutdown strategy as defined in the supervisor’s child specification
is an integer timeout value, not brutal_kill.
</pre>

即同浅,自定义之错就不曾为erlang shell认出来。

supervisor何时调用terminate()方法

末了一个题材来了,supervisor何时调用terminate()方法?之前分析到,关闭kernel进程的早晚,supervisor监控树进程会吸纳来自BootPid的{‘EXIT’,BootPid,shutdown}消息。我们解supervisor实际上一个gen_server,那么去看望外的handle_info()方法好了。

<pre>
-spec handle_info(term(), state()) ->
{‘noreply’, state()} | {‘stop’, ‘shutdown’, state()}.

handle_info({‘EXIT’, Pid, Reason}, State) ->
case restart_child(Pid, Reason, State) of %重启child
{ok, State1} -> %A
{noreply, State1};
{shutdown, State1} -> %B
{stop, shutdown, State1}
end;

handle_info(Msg, State) ->
error_logger:error_msg(“Supervisor received unexpected message:
pn”,
[Msg]),
{noreply, State}.
</pre>

此间代码显然还是handle_info
child发送过来的信号,调用restart_child()。在跟踪restart_child()进去,也从没看出原因:因为传播Pid并无是Child,而是BootPid,总是会活动及A分支,也就是说不见面调用terminate方法。这里陷入困境。
后来读书了supervisor文档,发现竟然没terminate()方法的说明,再次陷入困境。
说到底,想起supervisor实际上一个gen_server,应该去探望gen_server()文档对于terminate()方法地印证。
<pre>

Even if the gen_server is not part of a supervision tree, this function
will be called if it receives an ‘EXIT’ message from its parent. Reason
will be the same as in the ‘EXIT’ message.

</pre>
此说明,只要gen_server收到了来parent的’EXIT’
message,terminate()方法就见面调用。符合之前分析地:
<pre>
{‘EXIT’,BootPid,shutdown}
</pre>
至于BootPid和SuperVisor是否是parent关系,这里小没时间探究:不过一定会是,否则,顶层的sup一定要是有人通知关闭啊,而且BootPid从命名来拘禁,相当有或。这里留下一个坑后填上,主要是init:start()的开行。

2. exit/1 exit/2

其它
  • 之前代码中的player进程的child_spec的show_down写的是brutal_kill,这里肯定写错了;那么以关闭的下,自然非会见调用terminate方法
  • Erlang OTP之terminate
    深入解析当即首稿子是基于erlang
    14A本子的,他建议采用one_for_one。原因颇简单,erlang
    14A中,supervisor的terminate()函数如下
    <pre>
    terminate(_Reason, State) ->
    terminate_children(State#state.children, State#state.name),
    ok.
    </pre>
    对此17版,可以看,这里没处理单独simple_one_for_one的情况。因为simple_one_for_one和one_for_one的child信息于supervisor里面储存的凡休相同的:前者child存储于dynamics属性,
    来人存储于children属性。erlang
    14A的版本就处理了children里面的child,对于simple_one_for_one的child直接没有处理。
    对这篇文章的试,我以融洽电脑及吧举行了试验,确实同外的结果未平等。

exit有internal exits 和 external
exits的区分,我们得以使用exit(Pid,Reason)让别一个经过退出。

参考资料
  • Erlang OTP之terminate
    深入解析
  • erlang init
    stop浅析
  • erlang doc
  • ”Erlang supervisor 极其白痴的
    Bug“的正本清源——这首稿子提了生啊是erlang
    kernelProcess进程

exit/1和error/1非常相似,很多时可通用,便是exit语境是离,更称吃经过退出的动静,还有一个组别就是

exit/1非见面带动调用的stack
trace信息(方便于任何进程退出时不用带大充分的调用信息,更轻量)。但是error/1会带动。

4> catch exit(test).
  {'EXIT',test}
5> catch error(test).
   {'EXIT',{test,[{erl_eval,do_apply,6,
           [{file,"erl_eval.erl"},{line,674}]},
            {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,431}]},
            {shell,exprs,7,[{file,"shell.erl"},{line,686}]},
            {shell,eval_exprs,7,[{file,"shell.erl"},{line,641}]},
            {shell,eval_loop,3,[{file,"shell.erl"},{line,626}]}]}} 

3. throw/1

throw/1 它无限常用配合 try…of catch
处理嵌套case(可以迅速跳出),它所带的音最少(比exit/1还少一个’EXIT’):

6> catch throw(2+2).
4
7> catch 2+2
4     

方2只case用的catch,都分别无起结果是throw出来的,还是正常计算得到的结果,所以就为是引进以try
.. of catch的由来:

8> try throw(2+2) of
8> V -> {ok, V}
8> catch
8>  throw:V -> {error, V}
8> end.
{error,4} 

4. 总结

经过退出使用exit/1或exit/2,
想快跳出recursion或飞跃跨回Top-Level函数时用throw/1,尽量不要用error/1,

若是要获得调用的stack
trace信息,可以团结显式的调用erlang:get_stacktrace().得到时经过时一次Exception时时之的stacktrace。

 

5. 扩展(gen_server中之几栽退出过程方法比较)

 我们在gen_server中平安出5栽退出办法,

5.1. 在init不成功时返回{stop, Reason} 退出;
5.2. 处理消息出错,或正常退出时返回{stop, Reason, NewState});
5.3. 使用exit直接退出进程;
5.4. 使用throw退出进程;
5.5. 使用error退出进程(由于我们前面讲了error主要用于定义内部错误,所以不推荐使用)。

眼前少种是肯定的,关键是继三种植方法退出及前者的分别。

先行来料理一调理{stop, Reason, NewState},直接exit, 直接throw三者的区分。

https://github.com/erlang/otp/blob/maint/lib/stdlib/src/gen_server.erl#L601

try_dispatch(Mod, Func, Msg, State) ->
    try
    {ok, Mod:Func(Msg, State)}
    catch
    throw:R ->
        {ok, R};
    error:R ->
        Stacktrace = erlang:get_stacktrace(),
        {'EXIT', {R, Stacktrace}, {R, Stacktrace}};
    exit:R ->
        Stacktrace = erlang:get_stacktrace(),
        {'EXIT', R, {R, Stacktrace}}
    end.

动stop就是常规退出,不牵动stack
trace信息(他自就是从未有过crash,也从来不stack信息)

使用exit退出,它带了stack trace信息。

利用throw退出,它从不带来stack
trace信息,且要throw出来的term要是符合gen_server标准,比如

{noreply, NewState}
{reply, ok, NewState}
{stop, normal, NewState}

 

  

知了上述区别,就那个易选择了:

1.exit乎是用以不可预期的错,需要返回她的stack
trace信息之所以来记录,所以不推荐以gen_server中再接再厉调用exit;

2.throw方可快对此次信息之处理,简化代码的嵌套case逻辑,不过如果留意,throw出来的终将是一个相符gen_server标准的物,不然会报错。

3.正常化不过预料的逻辑都还应用{stop,Reason, NewState}处理。 

咱俩更深入一些:

当我们stop时的Reason不是 normal | shutdown |
{shutdown,term()} 时会在kernel log中打印日志

 

Notice that for any other reason than normal, shutdown,
or {shutdown,Term}, the gen_server process is assumed to terminate
because of an error and an error report is issued
using error_logger:format/2. 

遵循这样:

=ERROR REPORT==== 31-Oct-2016::15:10:44 ===
** Generic server test_throw_exit terminating
** Last message in was go
** When Server state == {state}
** Reason for termination ==
** not_shutdown_term

 

据此,如果我们当正常退出或shutdown时莫待那么同样排烦人的log,就将reason定义也三者中的同样种植就推行了。

现实源码可见:
https://github.com/erlang/otp/blob/maint/lib/stdlib/src/gen_server.erl#L809

总结:

  1. 在gen_server中正常退出,请复{stop, Reason, NewState},

2.
设是要是高速结束此次消息之退出可以采用throw(term()),其中term()符合gen_server规范(和健康返回的价一样),

  1. 正规逻辑之中未引进使用exit/error来拍卖,分带多余的stack
    trace信息。 

 

6. 参考资料:

  Erlang官方文档:http://erlang.org/doc/reference\_manual/errors.html

  Learnyousomeerlang关于Exceptions的介绍: http://learnyousomeerlang.com/errors-and-exceptions

图片 1

相关文章

admin

网站地图xml地图