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

Re: [Scheme-reports] (exit (error message obj ...)) should guarantee a failure exit code as understood by the local OS.

Ray Dillinger scripsit:

> Extending it to "any true value," on the other hand, would be
> counterproductive because that would not allow you to directly give
> the wide variety of more specific (success or) failure values that the
> local OS is prepared to interpret.

I agree.

> On the gripping hand, I have one proposed extension that I think is
> more needful and useful.  I think that the standard should state that
> calling exit with any error-object as a value causes your program to
> signal an exit with failure to the local OS.

I have filed ticket #374 to treat *any* uninterpretable object as #f.

> The current draft does NOT now specify the "meaning" of any argument
> other than #f.  It could specify #t, without causing any problems,
> but I don't think that really adds much value apart from being more
> tastefully symmetric.

The advantage of defining #t for success is that you can say (exit (=
error-count 0)) and the Right Thing happens.

> As I read this,

[correct but lengthy summary snipped]

> [A] few words clarifying the rationale could help prevent
> misunderstandings; otherwise someone might map *every* argument other
> than #f to "success" and lose the power to pass meaningful specific
> values to the OS.

I think the sentence "If an argument is supplied, the exit procedure
should translate the argument into an appropriate exit value for the
operating system" is sufficiently clear.

> However, I think it could make an additional useful requirement.  It
> could promise to signal an error exit when passed an error-object.

I think that #374 subsumes this; surely no OS will expect a complex
object like an error-object, which has a string and a list of arbitrary
Scheme objects inside.

> Error-objects, surely, are a category of things that can be expected
> to come in flavors at least roughly matching an operating system's
> categories of recognized program error types.

I doubt that.  In any case, Windows/Posix systems, unlike VMS, do not
have standardized meanings for error codes.

But I'm willing to be persuaded that there is a natural and universal
mapping between error objects and process exit codes that ought to be
standardized.  I'm just not persuaded yet.

John Cowan      cowan@x
        "Not to know The Smiths is not to know K.X.U."  --K.X.U.

Scheme-reports mailing list