[% setvar title One Should Not Get Away With Ignoring System Call Errors %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/


One Should Not Get Away With Ignoring System Call Errors


  Maintainer: Jarkko Hietaniemi <jhi@iki.fi>
  Date: 22 Aug 2000
  Mailing List: perl6-language@perl.org
  Number: 140
  Version: 1
  Status: Developing



If something fails, you should care.


In the following 'system calls' mean anything not in the core language calling an external service, be it a 'real' system call (such as accept(), fork(), mkdir()) or a 'library' call (such as print(), syswrite() getpwent()).

The difference is often arbitrary and depends on the implementation details of the operating system and the libraries. This difference is irrelevant for the purposes of this RFC (though relevant for the low-level implementation of this proposal).


The 'strict' pragma (or whatever form it takes in perl6) should include in its 'default set of strictness' a new subpragma, 'system'. This subpragma has the following semantics:

Cheating Is Still Possible

Not ignoring the return value is of course no guarantee of doing anything useful with the return value:

	$so_what++ unless defined fork();

But detecting whether 'something useful' is done is squarely in the realm of heavy AI.

Is That An Object In Your Pocket Or Are You Just Oriented To See Me?

This proposal does not deal with any object oriented issues, whether the detected errors 'throw' any 'exceptions' and how the user can 'catch' them. The proposed strict handling of system call failures should be independent of any higher level concepts such as object oriented 'exception handling'. Exception handling is welcome to provide ways to muster these low-level error conditions, though.


By having this new level of bondage-and-discpiline tucked away under 'use strict' the quick hack one liner nature of Perl is still available.