[erlang-questions] function badarg

[Ola Andersson A]

Great news with the line number in the crash. That will reduce my user support activities a lot. Thanx. ;-)

Regarding the original question I think that you should really consider some refactoring if you have a function with 1000 loc.
I remember an old rule of thumb saying that a MODULE should not contain more than about 400 loc.  
Personally I seldom use more than 10 lines in any function. That more or less eliminates any badmatches and it makes it that much easier to debug.
/OLA. 


-----Original Message-----
From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Kenneth Lundin
Sent: den 6 juli 2011 13:37
To: Gleb Peregud
Cc: erlang-questions
Subject: Re: [erlang-questions] function badarg

In this case I think it is of most interest to trace on function calls.
You will then be able to see the arguments that the loop function was called with just before the badarg crash and with that information you should be able to understand which function clause that was executing.

In the next major release  (R15B) planner for mid December there will be support for line numbers in crashes and it will be very easy to find exactly where you got the error.

If you get a badarg it is most probably a call to a BIF that fails.

/Kenneth Erlang/OTP, Ericsson

On Wed, Jul 6, 2011 at 11:04 AM, Gleb Peregud <gleber.p@REDACTED> wrote:
> try using dbg module to set up tracing of received messages. This will 
> at least tell you which branch might have matched and executed.
>
> On Wed, Jul 6, 2011 at 01:11, Robert Virding 
> <robert.virding@REDACTED> wrote:
>> For the moment, no. It is said that in R15 errors will not just include in which function they occur but also on which line. You get a badarg error when you make a system call or call to OTP libraries and the arguments are wrong, wrong type or illegal value.
>>
>> Robert
>>
>> ----- "Alexander Kuleshov" <kuleshovmail@REDACTED> wrote:
>>
>>> Hello,
>>>
>>> I have loop/2 function. This is main cycle of processing input data.
>>>
>>> Approximate form of this function:
>>>
>>> loop(Session, State) ->
>>>   {1} ->
>>>         .....
>>>        loop(Session, State);
>>> {2} ->
>>>         .....
>>>        loop(Session, State);
>>> {3} ->
>>>         .....
>>>        loop(Session, State);
>>> _ ->
>>>      loop(Session, State).
>>>
>>> In fact, this function big. Something about 1000 string of code.
>>>
>>> Sometimes this function crash with: Error in process <0.384.0> on 
>>> node 'test@REDACTED' with exit value: {badarg,[{test,loop,2}]}
>>>
>>> Is there instruments or methods to know where it occurs and how it 
>>> can catch this?
>>>
>>> Thank you.
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED
http://erlang.org/mailman/listinfo/erlang-questions