[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-local exits are icky

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

>>>>> "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
Tom> then?

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