BIF de retour

%EOF et %Found après toute opération pertinente. Pour tester
si un enregistrement n’a pas été trouvé sur une opération Chain, on code :

chain key file;
if not %found( file );
// Handle not found condition
endif;

Les BIF %EOF et %Found permettent toutes deux un argument
facultatif qui définit la source du retour. Si vous ne
codez pas un argument, la BIF fait référence à  la dernière
opération sur laquelle il pourrait être spécifié. Ainsi, la
BIF %Found fait référence à  file2, pas à  file1 :

chain key1 file1;
chain key2 file2;
if not %found file( );

On ne peut coder la BIF %Error qu’après une opération
qui spécifie l’extension d’erreur. Pour tester une erreur sur
une opération Write, on codera :

write(e) format;
if %error();
// Handle error
endif;

Contrairement à  %EOF et %
Found, %Error ne prend pas d’argument
pour définir l’origine du retour.
Il faut coder la BIF %Error immédiatement
après l’opération qu’elle référence.
%Error s’avèrera particulièrement
utile pour tester des valeurs
valides avant de forcer des données à 
changer de type. Le code suivant teste
une date *ISO dans un champ entier avant de le transformer
en un type date :

test(de) *iso int;
if not %error();
date = %date( int: *iso );
endif;

Ce fragment de code stoppe une erreur explosive sur la
BIF %Date. Cependant, les BIF
de retour ne stoppent pas normalement
les erreurs radioactives.
L’échec de détection d’une
erreur sur une opération Chain
ou Read signifie que les champs
d’entrée conservent leurs valeurs
provenant de la dernière opération
d’I/O réussie. On finit par réutiliser
des valeurs erronées plutôt
que de traiter l’erreur.