Handle read error

[lobaton_cebrian__edu]

Hello!

I am converting almost 2000 binaries files into text files. I have to make sure that in case a binary file is not properly formed, I can continue with all the rest. 

I am using this command to catch errors and continue execution in statement #40

                             read(1, IOSTAT= IOstatus, ERR=40) v_Fluor(j)

Any idea why this READ command is not working? The program fails and ends with the message: Project.exe hsa triggered a breakpoint.

Hope it is just a syntax issue.

Thanks.

[jimdempseyatthecove]

Try building your application in Debug mode with all runtime diagnostics enabled.

One possible reason if your program is in Release mode is if J indexes v_Fluor out of range. This is not a READ error as such, but a memory fault should the address be invalid to the process. Note, an index out of range of v_Fluor might not necessarily abort the read, but it may trash your program.

The runtime diagnostic of interest is to verify the array bounds are correct.

Jim Dempsey

[lobaton_cebrian__edu]

Thank you so much, Jim. I am executing my project in Release Mode, and I have forced this error to check how robust the error handling is.

I am receiving files from different sources, so I have to implement an error control that manages any entry. My problem is why "READ(1, IOSTAT= IOstatus, ERR=40) v_Fluor(j)" is not working. My problem is about why it stops and does not continues executing in statement #40.

Thank you again, Jim.

[mecej4]

I find that so many pieces of information are missing that not much can be said except to ask for them.

If you actually ran in release mode inside VS, the program would have run to completion -- whether normal completion or after running into an error and printing a corresponding message, if that is enabled, unless you have deliberately set the breakpoint that was hit.

We don't know what the file contains, what specifiers were used in the OPEN statement, what you mean by "binary file" or "properly formed" or "not working", and the type of the variable(s) in the I/O list. Suppose, for instance, that v_Fluor is an integer array. Why would be an "improperly formed" byte sequence in the file that you expect to cause the ERR= clause to go into effect?

Suppose, further, that v_Fluor represents the hour on a 24 hour clock. Any values less than 0 or greater than 23 are errors, from the point of view of your application. From the Fortran viewpoint, however, there is no error here; reading a 4-byte input containing 0x00000020, for example, would not cause the program to take the ERR= branch. You would need to write code to test for such errors and take appropriate action.

[jimdempseyatthecove]

Lobaton,

The READ may succeed to pull in the data to an internal buffer (hence no I/O error), but then the transfer of the data from the I/O buffer to v_Fluor(J) may fail due to J being some junk number (no I/O error, rather you get a GP fault which then presents a break point, should the runtime environment be configured to break on addressing errors). Additionally, a junk value for J could result in store of data to overwrite code, destroying some part of your program. The destruction can at times mimic a Debug Break point, adding to the confusion.

It won't hurt you to run through your files in Debug build, or at least with just the particular file that presents the error.

In the code you did not show, we do not know what the value of J is. We also do not know if v_Fluor is allocated, or if it is an optional dummy argument not provided on the call. Too many things are unknown about your program to offer advice with certainty.

Jim Dempsey

[lobaton_cebrian__edu]

jimdempseyatthecove wrote:

Lobaton,

The READ may succeed to pull in the data to an internal buffer (hence no I/O error), but then the transfer of the data from the I/O buffer to v_Fluor(J) may fail due to J being some junk number (no I/O error, rather you get a GP fault which then presents a break point, should the runtime environment be configured to break on addressing errors). Additionally, a junk value for J could result in store of data to overwrite code, destroying some part of your program. The destruction can at times mimic a Debug Break point, adding to the confusion.

It won't hurt you to run through your files in Debug build, or at least with just the particular file that presents the error.

In the code you did not show, we do not know what the value of J is. We also do not know if v_Fluor is allocated, or if it is an optional dummy argument not provided on the call. Too many things are unknown about your program to offer advice with certainty.

Jim Dempsey

Hello again! Jim, my question is not about why the READ command is not working, I do not care why the read is not working, I am trying to control the error, I am trying to handle the error, I need that when an error occurs, the program continue execution in another line. I know when it fails and I know why it is failing, because I have made the code to fail to catch the error.

Thanks. 

[mecej4]

I don't think that we are communicating well. May we try a different approach? Please present a short test code, including Fortran source, a small test "binary" file, and state what you expect the program to do and what it is actually doing.

I suspect that you incorrectly expect Fortran to have the same notion of "error" as your domain-specific notion of error, and I gave an example in #4. I see no evidence so far that the READ failed.

[jimdempseyatthecove]

Have you run the program in Debug build (no optimizations) and with all runtime checks enabled? Also, run the program from Microsoft Visual Studio IDE in Debug mode. This should identify almost all errors. As to how to fix them, that will be for you to discover (you have the code).

Jim Dempsey

[jimdempseyatthecove]

Placing ERR=40 on a READ statement does not catch non I/O related errors. This is not like a C++/C# try/catch type of programming.

Jim Dempsey

[lobaton_cebrian__edu]

Jim, Mece, I really appreciate your time and effort. Let me think a little bit deeper about this issue. 

I need more time to try different options, to make the program work.

Regards.

[mecej4]

Good luck, and please remember: Fortran has a much smaller set of detectable errors than you may be familiar with in an application area.

For example, there is a saying, "Don't push on the rope!"; if you wrote a Fortran program to calculate the tensions in a structure built out of steel wire, you should not be surprised to see some negative tensions in the results unless you supplied blocks of code to prevent that from happening!

In my kitchen I have a microwave oven with a timer. If I press "TIME" "1" "9" "9" "START", it beeps after 159 seconds. It takes the last two digits as the seconds field, but does not check if the entered value lies between 0 and 59.