|
|
| Author |
Message |
< Erlang ~ Erlang Error Detection/Handling Mechanism |
| Seb |
 Posted: Tue Mar 11, 2008 11:08 am |
 |
|
|
Joined: 10 Mar 2008
Posts: 5
Location: Canada
|
Hello,
I'm a newbie and I'm trying to understand how the Erlang Error Detection and Handling Mechanism works. What I understand is that Erlang does NOT use "defensive programming" and tries to establish some distinction between error detection and error handling.
I don't really understand what "defensive programming" refers to... Is the C++ code bellow an example of defensive programming ?? Are Java try-catch statements defensive programming ??
int f()
{
int a[10];
cin >> x;
if (x > 9 ) cout << "error\n"; else a[x] = 10;
}
Any help would be greatly appreciated.
Best regards,
new erlang user |
|
|
| Back to top |
 
|
| Mazen |
| Posted: Tue Mar 11, 2008 5:11 pm |
|
|
|
User
Joined: 20 Jul 2006
Posts: 164
Location: London
|
Hi Seb, This is my take at the definition.
The goal is to be able to patternmatch as much as possible. Lets say that you are extracting some data out of a table. The defensive version could look like this:
Code:
get_my_data(Id) ->
case get_data(Id) of
Data when is_record(Data, datarecord) ->
Data#datarecord.mydata;
Data ->
{error, data_error}
end.
The offensive version could look like:
Code:
get_my_data(Id) ->
#datarecord{ mydata = MyData } = get_data(Id),
MyData.
Now if you consider these two versions, then the first would force you into handling the {error, data_error} tuple in *every* possible call where the return value can be sent or used. Usually this is avoided by handling the error in the function that called it E.g in the following function.
Code:
fetch_my_data(Id, _OtherArguments) ->
case get_my_data(Id) of %% Call the function here
%% and be ready for errors
{error, Reason} ->
io:format("Error when fetching data~n"),
write_logs("Some log line...~n"),
{error, Reason}; %% Could be anything
TheData ->
TheData
end.
What we now realize is that we have to do this again... and again and again... until we reach some part of the code where we *actually* need to handle the error and don't need to return it back anymore (like a clean up function or some kind of failback perhaps).
Also this makes the code bulky... you must have ifs and case everywhere and you have to validate internal results etc. If everything looks right you *should* be able to write expressions like this in your code:
Code:
fetch_my_data(Id, _OtherArguments) ->
get_my_data( transform_id( create_new_transformer(
find_available_resource()
), Id)).
or
Code:
my_fun() ->
[{elements,[FirstElement,SecondElement|_]}]
= get_something(),
{FirstElement, SecondElement}.
Now I'm not arguing that the first example necessarily is beautyful, just that it get to the point  . The second example though is very efficient and save you both time and headache.
The point is that you handle the errors on top of your structure so that you can don't have to care about them inside the code. You handle them where it matters, where you do something about them and the easiest way to do that is to *crash*! because then you will go straight up the the nearest catch and say "hey something went wrong".
But the most important part of offensive programming is that when there is an error... you will *know*. IF there is an error then either you didn't account for it or it's a bug... and either way you want to know about it, you don't want error to be silently going on in your system. you want to fix them
Anyway.. that is the way I see offensive programming.
Hope it gave you some boost |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
