[erlang-questions] Debug support on for guards?
Henning Diedrich
hd2010@REDACTED
Sun May 2 17:26:25 CEST 2010
Thanks a lot,
also for clarifying the use of throw and error on the occasion!
Henning
Fred Hebert wrote:
> Untested:
>
> milli_epoch({Mega, Sec, Micro}) when
> is_integer(Mega), is_integer(Sec),
> is_integer(Micro),
> Mega >= 0, Sec >= 0, Micro >= 0 ->
> Mega * ?BILLION + Sec * 1000 + trunc(Micro / 1000);
> milli_epoch({Mega, Sec, Micro}) when
> is_integer(Mega), is_integer(Sec), is_integer(Micro) ->
> erlang:error(negative_input).
>
> Notice that I used erlang:error/1 rather than throw/1. The reason is
> that throw/1 is meant to be used mainly for control flow or very
> common exceptions you know how to fix, and should never be seen by the
> programmer -- they ought to be restricted to the module where they
> happen. Errors represent a piece of code you want to fail but you
> can't expect to fix without changing the code.
>
> On Sun, May 2, 2010 at 3:52 AM, Henning Diedrich <hd2010@REDACTED
> <mailto:hd2010@REDACTED>> wrote:
>
> Hi folks,
>
> is there a way to add detail to a function_clause error messages?
> Be it guards or patterns that don't match?
>
> On a crash, I would like to clarify what guard failed, or even
> warn the programmer that this guard exists when it may not be
> intuitive.
>
> 1
>
> This is written, I believe, as it should:
>
> milli_epoch({Mega, Sec, Micro}) when
> is_integer(Mega), is_integer(Sec), is_integer(Micro),
> Mega >= 0, Sec >= 0, Micro >= 0 ->
> Mega * ?BILLION + Sec * 1000 + trunc(Micro / 1000).
>
> 2
>
> This fails the way I would like it to, giving "negative_input" as
> reason.
>
> But it is written wrong for two (2) counts I believe (I am NOT
> trying to sneak in a point about ifs):
>
> milli_epoch({Mega, Sec, Micro}) when is_integer(Mega),
> is_integer(Sec), is_integer(Micro) ->
>
> if (Mega >= 0), (Sec >= 0), (Micro >= 0) -> ok;
> true -> throw(negative_input) end,
> Mega * ?BILLION + Sec * 1000 + trunc(Micro / 1000).
>
> Thank you very much for taking a look,
>
> Henning
>
>
>
More information about the erlang-questions
mailing list