[plt-scheme] Idiomatic equivalent to exn:application in v299?

On Feb 6, 2005, at 4:59 PM, Richard Cobbe wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> <sigh>
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on a mailing list?
>         -- .sig, Julien Salort <lists at juliensalort.org>
>
>
> On Sun, Feb 06, 2005 at 03:34:47PM -0500, Sam TH wrote:
>>   For list-related administrative tasks:
>>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
>> I think what you're looking for is raise-mismatch-error, which has the
>> same contract that make-exn:application:mismatch had.
>>
>>
>> On Sun, 6 Feb 2005 13:47:51 -0500, Richard Cobbe <cobbe at ccs.neu.edu> 
>> wrote:
>>>   For list-related administrative tasks:
>>>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>>
>>> Greetings, all.
>>>
>>> I'm in the process of porting some old libraries from 208 to 299, and
>>> I'm struggling a little bit with the new exception hierarchy.
>>>
>>> Here's an example: I've got a library for implementing standard 
>>> rib-cage
>>> environments.  In the old version, the lookup function would raise an
>>> exn:application:mismatch exception if the requested identifier is not
>>> bound, and I'd put the unbound identifier into the exception's value
>>> field.  (This follows hash-table-get's interface.)
>>>
>>> What's the idiomatic equivalent under v299?  It appears from the docs
>>> that the exn:fail:contract exception is the replacement for
>>> exn:application:mismatch, but there's no value field.  Is there a
>>> standard equivalent?  I'd really prefer not to marshal the value into
>>> the message string, as the new hash-table-get does.
>
> Well, raise-mismatch-error saves me from having to marshal the bogus
> value into the error string manually, but I still end up with (some
> representation of) the bogus value in the error string.  I'm still not
> wild about this.  I've used too many badly-designed libraries that
> expect my code to parse some random error string in order to be able to
> determine the error condition so I can take appropriate action.
>
> Richard
>
>

Gee, I love having responses all the way down here.  That way, all of 
the people on plt-scheme get to scroll down to the bottom of their 
message to see a 2 line response.  Genius!

-Felix

----
"the screens are sweet
  flat as a 8 yearold girl"  -josh, re: the new O2 monitors