why is the error reason in a catch/try truncated?

[Steve Strong]

Nope, you're not the only one. Loosing exception information like that can be very frustrating.

-- 
Steve Strong
twitter.com/srstrong


On Tuesday, January 18, 2011 at 3:52 PM, Joe Armstrong wrote:

> I have a program.
> 
> When I run the "uncaught" version it prints a very nice error message like
> this:
> 
> 
> > compile_file(File, Args, ParseTree).
> > 
> > 
> 
> {"init terminating in
> do_boot",{badarg,[{lists,member,[free_index,all_keys]},{ecc_db,add_to_list,2},{ecc_db,store,2},{ecc_pass1,start,2},{ecc_compile,compile_file0,3},{ecc_compile,compile_file,3},{ecc,batch,1},{init,start_it,1}]}}
> 
> This tells be exactly were I bombed.
> 
> In my "production" version of the code I add wrapper with a catch/try to
> trap any unwanted errors.
> So I write:
> 
> compile_file(File, Args, ParseTree) ->
>  case (catch compile_file0(File, Args, ParseTree)) of
>  {'EXIT', Why} ->
>  io:format("Compile file:~s aborted with:~p ~n",[File, Why]);
>  _ ->
>  ok
>  end
> 
> But when i run this
> 
> 
> > compile_file(File, Args, ParseTree).
> > 
> > 
> Compile file:first.c aborted with:error badarg
> 
> So the Why in the error tuple has lost all the useful information that was
> in
> the untrapped code.
> 
> To find the error I have to comment out the wrapped version and
> run the unwrapped version. This is because Why is just the atom
> badarg and not the more verbose {badarg, ...}
> 
> I find this behavior very unhelpfull - am I the only one?
> 
> 
> /Joe
> 
> 
>