[racket] Contracts error message

From: Daniel Prager (daniel.a.prager at gmail.com)
Date: Sun Sep 8 17:06:24 EDT 2013

For the consideration of Robby et al:

The clearest run-time errors I ever received were dumped out of SmallEiffel
/ SmartEiffel in response to contract violations.

These were stack-traces that -- critically -- included parameter values and
local state information for each stack frame.  Blame for pre- and
post-condition violations were easy to read off, down to the line / column.

Example from http://www.minimalprogramming.org/proglang.pdf pp177-:

*** Error at Run Time ***: Require Assertion Violated.
*** Error at Run Time ***: consistent_balance
3 frames in current stack.
===== Bottom of run-time stack =====
System root.
Current = TEST#0x8061a60
line 4 column 2 file ./test.e
======================================
make TEST
Current = TEST#0x8061a60
account = Void
line 8 column 4 file ./test.e
======================================
make ACCOUNT
Current = ACCOUNT#0x8061a88

  [ minimal_balance = 0.000000

    balance = 0.000000

  ]

a_minimal_balance = 100.000000
initial_balance = 10.000000
line 7 column 42 file ./account.e
===== Top of run-time stack =====
*** Error at Run Time ***: Require Assertion Violated.
*** Error at Run Time ***: consistent_balance


The author remarks, "That’s what I call a comprehensive error description.
Not only do we get the name of the violated condition and the values of the
parameters passed to the constructor method, but also the state of the
account object in question."

This could be improved further.  When I rolled my own contracts for C#
(pre-MS code contracts) I captured and reprocessed the stack trace to
included a "----->" to point at the line/column reference to the calling
code (for a pre-condition violation) or the supplying code (for a
post-condition violation).  I also reversed the direction of the trace so
that errors would appear at the top, thereby avoiding having to read down a
long trace when the error was usually apparent from the the top.

But those aspects are sugar, although pedagogically usefully and
practically very convenient.  Frustratingly, what I couldn't do, was dump
out parameters (and state) automatically, necessitating manual annotation
in the contract violation messages (which then became a risk/reward
trade-off).

Cheers

Dan


On Sun, Sep 8, 2013 at 11:40 PM, Robby Findler
<robby at eecs.northwestern.edu>wrote:

> You are not the only one to complain :). We've been having an internal
> discussion about this, actually.
>
> In this particular, case, I think that you are using provide/contract,
> right? If so, the blame really lies with the entire file edf.rkt. So there
> really isn't anything more specific to say.
>
> Robby
>
>
>
> On Sun, Sep 8, 2013 at 4:20 AM, antoine <antoine597 at gmail.com> wrote:
>
>> Hello,
>>
>> I have just start using contracts in racket, but i am a bit disapointed
>> by the
>> error message they give to me.
>>
>> example contract error:
>>
>>  add-number: contract violation
>>  expected: number?
>>  given: "1"
>>  in: the 2nd argument of
>>       (-> number? number? number?)
>>  contract from: abc.rkt
>>  blaming: edf.rkt
>>  at: abc.rkt:5.3
>>
>> I would have expected to have the line and column number in the blaming
>> line
>> like what you could get from a stacktrace.
>>
>> Is it possible in contracts?
>> Am i the only one to complain? :)
>>
>> Thanks you in advance.
>> ____________________
>>  Racket Users list:
>>  http://lists.racket-lang.org/**users<http://lists.racket-lang.org/users>
>>
>
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>
>


-- 
*Daniel Prager*
Agile/Lean Coaching, Software Development and Leadership
Twitter: @agilejitsu <https://twitter.com/agilejitsu>
Blog: agile-jitsu.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130909/b59bc9bd/attachment.html>

Posted on the users mailing list.