My paragraph after that was ~= I don't understand the need to do
anything with a exn:fail:contract except show the user and exit.
IIUC that's already the default behavior for non-GUI Racket apps, when
some code is being hopeless.
1. Some other codes notices and raises exn:fail:contract.
2. The un
As Ben pointed out, if the exception is a `real exn:fail:contract:blame`,
you don't even need to parse the message string:
#lang racket
(define/contract (wants-exact x)
(-> exact? exact?)
x)
(define/contract (wants-inexact x)
(-> inexact? inexact?)
x)
(define (show-which-was-violated x)
On Mar 25, 2019, at 12:49 PM, Matthias Felleisen wrote:
> See how precise the exn message is: 2nd arg of 1st arg of f ~~ not a boolean?
Okay. So the exn message is generated in a systematic way which I can count
on. I didn't realize that. Thanks.
--
You received this message because you
> On Mar 25, 2019, at 12:30 PM, James Platt wrote:
>
>
> On Mar 25, 2019, at 12:05 PM, Matthias Felleisen wrote:
>
>> Your exception handlers may test a contract failure to any level. You can
>> specify this in the predicate part of with-handlers or via match on the exn
>> within the handl
On Mar 25, 2019, at 12:05 PM, Matthias Felleisen wrote:
> Your exception handlers may test a contract failure to any level. You can
> specify this in the predicate part of with-handlers or via match on the exn
> within the handler function. Regexp matching works well here.
It's obvious enoug
> On Mar 25, 2019, at 11:59 AM, James Platt wrote:
>
>
> On Mar 23, 2019, at 5:49 PM, Greg Hendershott wrote:
>
>> But -- contract violations aren't like that. They're about some code
>> surprising some other code. I think the only hope here is, run the
>> code enough (before the user ever d
On Mar 23, 2019, at 5:49 PM, Greg Hendershott wrote:
> But -- contract violations aren't like that. They're about some code
> surprising some other code. I think the only hope here is, run the
> code enough (before the user ever does) to flush out the bad code
> assumptions and fix them. Realist
Using `exn->string` from `racket/exn` should usually include context
("stack trace")?
https://docs.racket-lang.org/reference/exns.html#(def._((lib._racket%2Fexn..rkt)._exn-~3estring))
Also there will be more context to see, if in DrRacket or racket-mode
you've selected that higher level.
p.s
On 3/23/19, David Storrs wrote:
> Alex makes good points, but I'm curious about the original question: Is
> there a straightforward way to tell which function it was whose contract
> was violated, aside from parsing the message? Or, more generally, where a
> specific exception came from?
For bl
Alex makes good points, but I'm curious about the original question: Is
there a straightforward way to tell which function it was whose contract
was violated, aside from parsing the message? Or, more generally, where a
specific exception came from?
On Fri, Mar 22, 2019 at 7:17 PM Alex Harsanyi
On Saturday, March 23, 2019 at 5:17:22 AM UTC+8, James Platt wrote:
>
> Well, I might make some kind of compromise. What I don't want to allow is
> the possibility of the user experience being "I click on the button and
> nothing happens."
You can wrap each button callback with a `with-hand
Well, I might make some kind of compromise. What I don't want to allow is the
possibility of the user experience being "I click on the button and nothing
happens." Next worst is to display a raw error message which the user can only
interpret by cutting and pasting it into a web search. So ye
I'm working on displaying informative error messages in a GUI and I have been
finding that many of the things I need to handle are contract violations in
downstream functions. The thing is that it seems like there ought to be a
better way than the methods I can think of.
It's very simple to
13 matches
Mail list logo
