# Ioerror to skip further processing

**URL:** <https://fortran-lang.discourse.group/t/ioerror-to-skip-further-processing/5930>\
**Category:** Language enhancement\
**Created:** [June 7, 2023, 3:08pm UTC](https://fortran-lang.discourse.group/t/ioerror-to-skip-further-processing/5930 "2023-06-07T15:08:25Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![egio](https://avatars.discourse-cdn.com/v4/letter/e/dbc845/32.png) [@egio](https://fortran-lang.discourse.group/u/egio)\
**Post date:** [June 7, 2023, 3:08pm UTC](https://fortran-lang.discourse.group/t/ioerror-to-skip-further-processing/5930/1 "2023-06-07T15:08:25Z")

</div>

Lately I’m writing and reading from a file many arrays.  
The easier way to check that the reading or the writing have been correct is to use the old go to label **err** inside each input or output statement like in:

```fortran
open(newunit=lun, file='filename', ..., err=1)
...
write(lun, ..., err=1) a, b, c
write(lun, ..., err=1) aa, bb, cc
write(lun, ..., err=1) ...
...
close(lun)
return 
1 continue
  close(lun, status='delete') ! perhaps I don't want an half file
print *, 'Error'

```

Now, one can, instead of using a label, check an **iostat** variable every statement like in:

```fortran

open(newunit=lun, file='filename', ...)
writing: block
   ...
   write(lun, ..., iostat=ios) a, b, c
   if (ios/=0) exit writing
   write(lun, ..., iostat=ios) aa, bb, cc
   if (ios/=0) exit writing
   write(lun, ..., iostat=ios) ...
   if (ios/=0) exit writing
   ...
   close(lun)
   return 
end block writing
  close(lun, status='delete') ! perhaps I don't want an half file
print *, 'Error'

```

But that definitely double the number of required statements.  
What would be nice will be to retain the small number of output lines while not using a label for error detection.

The proposal is this one:  
There is an almost opaque type in `iso_fortran_env` called: `io_error_type` (or whatever name could be used).  
the `open` statement accept an optional intent(out) `io_error` variable of type `io_error_type`.  
The `io_error` variable can be in two state: `error`, or `ok`. This state can checked with an appropriate function. The `io_error_type` contains also the information that are stored into `iostat` variable and the `iomsg` variable that can be read with appropriate functions (so you don’t need to pass also this two other variables).

The presence of the `io_error` variable will make the open behave like when `err` variable or `iostat` variable is present. Basically the variable is set with the appropriate error condition or with the no error condition.

But that is almost syntactic sugar, what it will be different is what happen when the variable is passed to the `write` or `read` statement.

The `read` and `write` statements will accept an `optional`, `intent(inout)` `io_error` variable. If the variable is in the ok condition it can be set to an error condition if an error happen during the `io` activity, while if contains an error condition there is no **io** activity and the variable is left unchanged, basically passing along the chain the error. Basically the previous program will be:

```fortran
use iso_fortran_env, only: io_error_type
type(io_error_type) :: ioe

open(newunit=lun, file='filename', io_error=ioe)
...
write(lun, ..., io_error=ioe) a, b, c
write(lun, ..., io_error=ioe) aa, bb, cc
write(lun, ..., io_error=ioe) ...
...
if (.not. is_in_error(ioe)) then
   close(lun) 
else
   close(lun, status='delete') ! perhaps I don't want an half file
   print *, 'Error'
endif

```

One may also add an option to `close` like:

```fortran
close(lun, io_error=ioe, staus='delete_if_error')

```

Which may be useful when writing a file (not when reading of course). So the last part may be:

```fortran
write(lun, ..., io_error=ioe) 
...
close(lun, io_error=ioe, status='delete_if_error')
if (is_in_error(ioe)) print *,'Error', get_error_message(ioe)

```

Now if one add the possibility to set this `io_error` variable in some way it may be used also in other part of a program (but is will be easy with an ad hoc user defined type, while the use in the `write` and `read` statement should be supported by the compiler) .

I hope you like it, tell me. 🙂  
Cheers

---

<div class="post-metadata">

**Author:** ![egio](https://avatars.discourse-cdn.com/v4/letter/e/dbc845/32.png) [@egio](https://fortran-lang.discourse.group/u/egio)\
**Post date:** [June 7, 2023, 5:12pm UTC](https://fortran-lang.discourse.group/t/ioerror-to-skip-further-processing/5930/2 "2023-06-07T17:12:04Z")

</div>

Yes, I could have written something like:

```fortran
...
if (ios==0) write(..., iostat=ios) ...
if (ios==0) write(..., iostat=ios) ...
if (ios==0) write(..., iostat=ios) ...

```

So it is a sort of syntactic sugar, but it’s a bit ugly. Moreover, I have spoken of a `io_error` variable but it could be a `ios_file_info` variable that store also the logical `unit`.

So the use is open to other possibility.  
Cheers

---

<div class="post-metadata">

**Author:** ![feenberg](https://avatars.discourse-cdn.com/v4/letter/f/c2a13f/32.png) [@feenberg](https://fortran-lang.discourse.group/u/feenberg)\
**Post date:** [June 8, 2023, 12:24pm UTC](https://fortran-lang.discourse.group/t/ioerror-to-skip-further-processing/5930/3 "2023-06-08T12:24:54Z")

</div>

My objection to all 5 of these proposed patterns is that they conceal the location and reason for the error. If error handling were left entirely to the compiler not only would the code be simplified, but a statement number and error message would be available (with appropriate compiler options). While the ultimate user may not be able to interpret the error message, at least they will have something of substance to show whoever they enlist for help.

I am aware that the programmer could provide a useful error message, but that is fairly unusual. The common case is to discard any information about the cause of the error and substitute a generic message.

FWIW, my two favorite error messages, both from OS/3360:

1: “Illegal error” (hardware returned an error code unknown to the OS)  
2. “Illegal compiled format” (subscript out of bounds overwrote format)

Both of these seemed quite obscure at the time, but did eventually lead to corrections. Providing nothing at all would have been worse.

---

<div class="post-metadata">

**Author:** ![egio](https://avatars.discourse-cdn.com/v4/letter/e/dbc845/32.png) [@egio](https://fortran-lang.discourse.group/u/egio)\
**Post date:** [June 8, 2023, 3:29pm UTC](https://fortran-lang.discourse.group/t/ioerror-to-skip-further-processing/5930/4 "2023-06-08T15:29:07Z")

</div>

I think, well…, it depends.

But I understand your concerning about poor written error message and the “let crash the program then it will be easier for me to understand where is the problem!” feeling.
