I/O error handling

[wjg]

We are using some legacy Fortran code in our DLLs. These Fortran DLLs are called from a C++ application. The problem we are having is that if there is an I/O (read,write) error in the Fortran DLL, Fortran displays a message with a traceback and then it terminates the application.

Unfortunately, the I/O statements in this legacy code where written without ERR or EOF labels. It would be quite a task to go back and modify the Fortran code. Is there a way that we can direct Fortran to throw an exception that can be caught by the C++ application?

Thanks.

[Jugoslav_Dujic]

AFAIK, no; (but I eagerly wait if Steve could prove otherwise).

To my knowledge (so take the following with the grain of salt).

Take a look at "Run-Time Environment Variables" help page, and particularly FOR_IGNORE_EXCEPTIONS and FOR_DISABLE_DIAGNOSTIC_DISPLAY variables. The former, however, affects only the built-in catching of "naturally" thrown exceptions, such as floating-point ones, array out of bounds, and access violations. However, I'm affraid that there is no way to induce RTL/compiler to throw an exception when it encounters a fatal error.

In other words, the pseudo-code of run-time library looks like:

!RTL exception handler:
if (not defined(FOR_IGNORE_EXCEPTIONS))
  try {
  ...
  }
  catch {
  if (not defined (FOR_DISABLE_DIAGNOSTIC_DISPLAY))
     MessageBox("Exception %1 -- program will be terminated")
  end if
end if

However, when an illegal situation (but not a "native" exception), such as I/O error is detected, the code looks like:

if (present(iostat)) then
  iostat = iErrorCode
else
  if (not defined (FOR_DISABLE_DIAGNOSTIC_DISPLAY))
     MessageBox("I/O error: File not found")
     Traceback(...)
  end if
  ExitProcess()
end if

To my knowledge, there's no way to induce the compiler to throw an exception, instead of unconditionally calling ExitProcess() in the absence of iostat.

To overcome the problem, I even tweaked ALLOCATE statement by replacing default RTL routine for_alloc_allocatable (so that it calls RaiseException rather than dying). However, that would be hardly possible with I/O ones such as READ/WRITE.

[wjg]

Thanks for the info Jugoslav. We will look into this matter some more.

William