[erlang-questions] feedback please
Roelof Wobben
r.wobben@REDACTED
Thu Sep 24 08:22:27 CEST 2015
Op 24-9-2015 om 08:04 schreef Roelof Wobben:
> Op 24-9-2015 om 07:56 schreef zxq9:
>> On Thursday 24 September 2015 07:41:40 Roelof Wobben wrote:
>>> Thanks,
>>>
>>> You are right. I did take a quick look and almost the whole chapter is
>>> try .. catch. So match or chrash is better ?
>> It is not so much of a matter of which is "better" -- but that *most*
>> of the time you want to follow the mantra of "let it crash" and this
>> is a very natural fit for Erlang. For example, if I start a process
>> that is supposed to read some configuration settings in its init/1
>> section before it gets going, and the config data is all screwed up
>> (wrong format, maybe its not even the right data -- like binary image
>> data instead of a settings file or something) then I don't want to
>> try..catch and then write extra code to force the process into some
>> semi-workable state and carry on. I want to just crash right away.
>>
>> In development this might just be something that explodes in my
>> terminal. BOOM! And then I know I need to look at something right away:
>> "Why the devil am I sending image data where a file name is supposed
>> to go?"
>>
>> In production it may be an indicator that some remote resource you
>> normally query has changed its API:
>> "Oh boy, our [very important to your business] service changed their
>> protocol unannounced... again...".
>>
>> In either case the last thing you want to do is have the processes
>> silently carry on and crash *other* processes (or other services!)
>> *way later* for reasons that are now at least one degree removed from
>> the actual problem.
>>
>> But occasionally you will want a try..catch. Sometimes you just want
>> to be able to stay alive long enough to log a very specific/detailed
>> error in a natural way; sometimes you are dealing with an unknown
>> platform and interacting with a user at the same time, and you're not
>> sure what sort of data you might receive -- but if the data is bad
>> you need to stay alive long enough to tell the user about it in
>> detail. In cases like these you *can* accomplish this without
>> try..catch, but its really annoying. In most cases, though,
>> try..catch is much more annoying (and downright dangerous compared to
>> crashing immediately).
>>
>> In my experience try..catch is something you'll know when you need,
>> and that need is infrequent. Almost any time you use try..catch you
>> are not writing for the "success case" (or "happy path") -- the rare
>> times that try..catch fits into the "happy path" not having it would
>> be an annoying handicap.
>>
>> So its not that "crashing is better than try..catch" so much as
>> "standard Erlang practice is to crash on faults, and try..catch is a
>> very useful tool in some specific cases", so you do need to know
>> about it.
>>
>> -Craig
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> -----
>> Geen virus gevonden in dit bericht.
>> Gecontroleerd door AVG - www.avg.com
>> Versie: 2015.0.6140 / Virusdatabase: 4419/10690 - datum van uitgifte:
>> 09/24/15
>>
>>
>
> Thanks for the explanation. it's very clear what point you try to make.
>
> Roelof
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> -----
> Geen virus gevonden in dit bericht.
> Gecontroleerd door AVG - www.avg.com
> Versie: 2015.0.6140 / Virusdatabase: 4419/10690 - datum van uitgifte:
> 09/24/15
>
>
On question pops into my mind.
You have this code for input the amount :
ask_amount() ->
Input = io:get_line("How much? "),
case scrub_amount(Input) of
{ok, Number} ->
Number;
{error, bad_input} ->
ok = io:format("Hrm... '~tp' does not seem to be a number~n"
"Now, one more time...~n",
[Input]),
ask_amount()
end.
If I want to check if the input is postive do I need to put a if then
into the {ok, number} piece.
Roelof
More information about the erlang-questions
mailing list