[% setvar title One Should Not Get Away With Ignoring System Call Errors %]
|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 <email@example.com> Date: 22 Aug 2000 Mailing List: firstname.lastname@example.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:
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.
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.