[plt-scheme] raise error

From: Rainer Gross (rainer_gross at gmx.net)
Date: Tue Jan 30 21:13:25 EST 2007

Very clarifying, thanks a lot.


On Jan 29, 2007, at 11:21 PM, Matthew Flatt wrote:

> At Mon, 29 Jan 2007 22:05:40 -0300, Rainer Gross wrote:
>> The following is the result in the interaction window of DrScheme:
>>> (with-handlers ([exn? (lambda (exn) (write (exn-message exn)))])
>>    (error "First part" "second part"))
>> "First part \"second part\""
> It's slightly less confusing if you use `display':
>> (with-handlers ([exn? (lambda (exn) (display (exn-message exn)))])
>      (error "First part" "second part"))
>  First part "second part"
> What you see now is that "First part" is the text of a message, while
> "second part" is printed as a Scheme value. Typically, the second and
> later arguments are Scheme values you want to talk about in an error
> message. Here's another example:
>> (with-handlers ([exn? (lambda (exn) (display (exn-message exn)))])
>      (error "This is not a string: " #\x))
>  This is not a string:  #\x
> At Mon, 29 Jan 2007 23:08:55 -0300, Rainer Gross wrote:
>> Since I am interested in raising error messages for the end user I
>> don't have any symbol to inform. Therefore the (error src-symbol
>> format-string v ···) definition is not useful in my case. But yes I
>> want to have the format string like behavior of this function or even
>> better the java like "hello" + a + "world".
> Then your entire error message should be the first argument to  
> `error',
> since you don't want to report any Scheme values in the error message.
> You may want to use `string-append' or `format' to construct the error
> message. Also, you probably want to call `raise-user-error' instead of
> just `error', as that will avoid other potential programmerese in the
> error message (such as a stack trace).
>> In PLT MzScheme Language Manual section 6.2 Errors it is the second
>> form I am using:
>> It says:
>> (error msg-string v ···) creates a message string by concatenating
>> msg-string with string versions of the vs (as produced by the current
>> error value conversion handler; see section A space is
>> inserted before each v.
> This is correct. The error value conversion handler converts a  
> value to
> a string that can be displayed to show the value's printed form:
>> ((error-value->string-handler) "hi" 10)
>  "\"hi\""
>> (display ((error-value->string-handler) "hi" 10))
>  "hi"
> That's the right sort of conversion for showing Scheme values in an
> error message, but not the right thing for inserting a string into an
> end-user error message.
>> I would like something like string-append but that is aware of type
>> and inserts the extra blanks as offered by (error msg-string v ...)
> We have no such function. I think it may be rare that concatenating
> strings with spaces is earlier than using `format' and produces an
> error message that looks right to end users (which is not to say that
> it isn't the right thing for your case, only that it seems rare enough
> that we don't have a built-in function for that).
> Matthew

Posted on the users mailing list.