forrtl:severe change the default handler

forrtl:severe change the default handler

We occassionally get forrtl errors of different types and they pop up a big message box with a stack trace and then cause our programs to terminate.  We would really like to handle these errors in a more professional manner.  The documentation for error handling seems to indicate that we can "change the default action", but I have not found the documentation that describes how to do this.  There are some examples for Linux, but there don't seem to be any for Windows.

Is it possible to change the default error handler?

14 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Are the errors floating point errors, memory allocation errors, file I/O errors, stack overflow errors, other...?
All to the above?

Have you read the Intel Fortran documentation? Using Index:
error handling | Run-Time Default Error Processing

and other sub-topics

Jim Dempsey

The errors are all of the above, but even if we could only improve the behavior for some of these errors it would be beneficial.

I have read the Intel Fortran documentation that you are referring to and this is where I have found the references to changing the default action.  Unfortunately there are only examples of how to change the default action on Linux and Mac.  There are no examples or documentation for windows.

In a release later this year we will be adding the ability to establish your own error handler, sort of. Right now, some types of errors you can change the processing of, others you can't. Which errors do you want to handle?

Retired 12/31/2016

We would like to handle all of the errors that can be handled.  Do you have any documentation on how to do this for the errors that can currently be handled?

There is existing documentation on your options here,but there are few exceptions you can handle - mainly those detected by the processor. And by "handle" it's generally have a routine that provides some additional reporting. The new facility will be more flexible and generally applicable.

Retired 12/31/2016

I have been searching for the documentation here, but I have not found anything.  Could you provide a more specific reference to where I should search?

Compiler Reference > Error Handling > Handling Run-Time Errors. The subsection "Advanced Exception and Termination Handling" is also of interest.

Retired 12/31/2016

Reading through this, it seems to indicate that there is no way to trap any File I/O errors.  Is this accurate?

One of the specific problems we are trying to trap is that the Intel Fortran compiler generates a severe error when standard out doesn't work.  According to Microsoft this is a normal situation though.  Is there any way to change the error class from severe to info for errors like this?

It is correct that you cannot trap I/O errors. In the future you will at least be able to intercept them and "do something", but turn them into informationals is not going to be possible. When you say "doesn't work", what do you mean? I can't imagine what a "normal situation" would be in this case.

Retired 12/31/2016

By "doesn't work", I mean that there isn't a standard output handle for this process.

By "normal situation", I mean many programs these days use GUIs and don't use a console.  It is common for these processes to not have a standard output handle associated with them.  It would be nice if the Intel Fortran compiler could be used to generate libraries that can be used reliably in GUI programs as well as console programs.

Now I'm confused.  We already do that. There was a short time, several years ago, when we gave an error for this situation but we backed out that change due to customer complaints.  I just did a test where I did a write to unit * from a "Windowing Application" (no console), and it worked fine - no error. Can you create a small test case that shows otherwise?

You can programatically detect the lack of a console by seeing if the result of calling GetStdHandle(STD_OUTPUT_HANDLE) is NULL and perhaps do something different, but simply writing to standard out (unit * or 6) should just result in the data being thrown away.

Retired 12/31/2016

It is possible that we are not using the most recent version of the Intel Fortran compiler.  I was hoping that any error trapping we found would be applicable to multiple versions.

In my testing, GetStdHandle(STD_OUTPUT_HANDLE) has generally returned a handle though this handle is not always valid.  WriteFile fails with error 6.

Which version are you using? I think we were giving an error for this sometime around the 12.0 release.

I did some more tests, and you're right, GetStdHandle returns an unusable handle if called from a non-console app unless AllocConsole has been called first. Very strange. But I still don't get an error on a Fortran write to unit * or 6 - the write is simply ignored.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today