[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: non-local exits are icky
>>>>> "Tom" == Tom Lord <lord@xxxxxxx> writes:
>> From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Tom> But I really don't understand your attitude here. To be consistent,
Tom> shouldn't you simply leave error conditions completely unspecified
It pretty much is. In fact, the SRFI has a sentence containing the
word "undefined" to describe what's going on.
Tom> How are you drawing this line between "error handling specifications
Tom> that are reasonable in this FFI" vs. "error handling that isn't"?
The errors in this SRFI are all about *bugs* (the SRFI says this).
Tom> I object to the idea that the errors signalled by the draft's
Tom> primitives indicate "a bug in your [the FFI-user's] program".
Tom> SCHEME_CALL* sure looks to me like a tool for adding an extension
Tom> language to your favorite C program -- so the bug may very well be in
Tom> a Scheme extension.
Sure it may be. But there's a bug somewhere. This SRFI talks about
bugs that occur in the C code (even though they may originate in the
Scheme code); the point is that *all* of these things can be avoided
by proper checking before use of the facilities defined in this SRFI.
Tom> Since the underlying issue here is error-code-returns
Tom> vs. non-local-exits-past-C, while I acknowledge that you can argue
Tom> against the positive reasons for error-codes, can you please explain
Tom> why you object to them?
Because I don't think a program should be able to get away, say, with doing
(car #f). I want a visible indication that something's wrong. This
SRFI, as is, already gives you plenty of bullets to shoot yourself in
the foot with. This seemed one too many.
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla