Error Handling in Fortran

Analogy categoryAnalogies

Fortran's Approach: Status Codes, Not Exceptions

Unlike languages with try/catch exception handling, Fortran uses explicit status-reporting arguments attached directly to the statements that can fail: IOSTAT for I/O statements, STAT for ALLOCATE/DEALLOCATE, and error-handling specifiers on other intrinsics, each returning an INTEGER that is zero on success and nonzero on failure. This means every potentially-failing operation must be checked immediately at the call site rather than relying on control flow unwinding to a distant handler, which keeps error paths visible in the code but places the discipline of checking every status code squarely on the programmer.

🏏

Cricket analogy: Checking IOSTAT after every read is like an umpire checking the light meter reading before every over, rather than waiting for a batter to complain of poor visibility after already being dismissed.

Handling I/O Errors

READ and WRITE statements accept an IOSTAT= integer variable and optionally IOMSG= for a descriptive string; IOSTAT returns zero on success, a negative value for end-of-file or end-of-record conditions (distinguishable via the IS_IOSTAT_END and IS_IOSTAT_EOR intrinsic functions), and a positive value for a genuine I/O error such as malformed data or a missing file. Combining IOSTAT with an explicit loop is the standard idiom for reading an unknown number of records from a file until EOF, replacing the older and less portable ERR= and END= label-based branching still found in legacy codebases.

🏏

Cricket analogy: Distinguishing end-of-file from a real I/O error with IOSTAT is like an umpire distinguishing 'innings over, target reached' from 'match abandoned due to rain', two very different reasons the play stopped.

Allocation Failures and ERROR STOP

ALLOCATE and DEALLOCATE accept STAT= and ERRMSG= specifiers analogous to IOSTAT/IOMSG, so ALLOCATE(bigArray(n), STAT=ierr, ERRMSG=msg) lets a program gracefully handle an out-of-memory condition instead of crashing, which matters in large simulations where n might exceed available memory. For genuinely unrecoverable conditions, ERROR STOP immediately terminates all images in a coarray program (or the single image in a non-coarray program) with a nonzero exit status and an optional message, distinct from the plain STOP statement, and is the idiomatic way to fail loudly and immediately when a precondition the rest of the program depends on has been violated.

🏏

Cricket analogy: Checking ALLOCATE's STAT= before using a huge array is like a stadium checking ticket-printer capacity before an unexpectedly oversold World Cup final, catching the shortfall before fans are turned away at the gate.

Structured Patterns for Robust Programs

A common idiom wraps a fallible operation and its status check in a small subroutine that returns its own STAT-like output argument, propagating failure information up through several layers of calls without exceptions, similar in spirit to Result-returning functions in Rust or Go's error return values. For numerical robustness, the IEEE_EXCEPTIONS intrinsic module (IEEE_GET_FLAG, IEEE_SET_HALTING_MODE) lets a program detect or trap floating-point conditions like division by zero and overflow, giving Fortran a standardized way to handle both I/O-level and arithmetic-level failure modes within the same status-code philosophy rather than mixing paradigms.

🏏

Cricket analogy: Propagating a STAT code up through several subroutine calls is like a fielding error being reported up from fielder to captain to coach in a post-match review, each level passing along what actually happened rather than hiding it.

IS_IOSTAT_END(ios) and IS_IOSTAT_EOR(ios) are the portable, standard-conforming way to test whether an IOSTAT value indicates end-of-file or end-of-record, rather than relying on a specific negative constant, which is not guaranteed to be the same across compilers.

Ignoring IOSTAT or STAT return values (omitting the specifier entirely) means a failed READ, WRITE, or ALLOCATE will, depending on the compiler and platform, either silently leave variables undefined or abort the whole program with a generic runtime error and no context about which operation failed. Always attach IOSTAT=/STAT= to operations that can plausibly fail, especially file I/O and large allocations.

Fortran uses status-code specifiers (IOSTAT, STAT) attached to individual statements instead of exceptions.
IOSTAT is zero on success, negative for end-of-file/end-of-record, and positive for a genuine I/O error.
IS_IOSTAT_END and IS_IOSTAT_EOR portably test the meaning of a negative IOSTAT value.
ALLOCATE/DEALLOCATE support STAT= and ERRMSG= to handle out-of-memory conditions gracefully.
ERROR STOP terminates the program immediately with a nonzero exit status for unrecoverable conditions.
Custom subroutines can propagate their own STAT-like output arguments up through call layers, Result-style.
The IEEE_EXCEPTIONS module extends the same status-checking philosophy to floating-point arithmetic errors.