Error Checking in an Elemental Function

[ronalddavis]

I would like to write an elemental function that will stop the program if an error occurs. However, a Stop statement in a pure function is forbidden*. Does anyone have any ideas about how to do it in a platform-independent manner? Dividing by zero will do it on some systems, but will only create a result called "infinity" on others.

(* Logically, this makes sense, because stopping is about the biggest side-effect one can imagine, but it won't cause any of the problems one normally associates with side-effects of pure functions.)

[Steven_L_Intel1]

I don't know of a portable way of doing this. You could fudge it by declaring RAISE as follows:

INTERFACE
PURE FUNCTION RAISE(SIGNAL)
!DEC$ ATTRIBUTES DEFAULT :: RAISE
!DEC$ ATTRIBUTES c,alias:'_raise' :: RAISE
INTEGER*4 RAISE
INTEGER*4 SIGNAL
!DEC$ ATTRIBUTES VALUE ::   SIGNAL
END FUNCTION
END INTERFACE
INTEGER, PARAMETER :: SIGABORT = 22

Then calling:

I = RAISE(SIGABORT)

Steve

[Edited to correct typo in code]

[ronalddavis]

Thank you. Your answer provides a completely satisfactory solution to my problem. I have always kept my functions and subroutines in modules, so that I can always be sure that the compiler is correctly informed about the function or subroutine's interface. So ingrained is this custom in me, that I had forgotten that one can use an Interface block for a function or subroutine that is not in a module. However, it seems that one can thus declare any function or subroutine to be pure, no matter how impure it really is.

The fact that I can fool the compiler in this manner reinforces my determination to keep my functions and subroutines in modules, except when hypocrisy is called-for. I think the fundamental problem here is with the standard. A Stop or Call Exit statement should be permitted in a Pure function or subroutine. Even though it might be said to have a side-effect, it will not cause the problems one associates with side-effects.

[Steven_L_Intel1]

Oh, but it might indeed have nasty consequences - especially if parallel processing was involved. You might end up with hung threads, or worse.

Exiting a program from deep within is not good programming practice anyway - you are better off trying to inform the caller of an error so that it can be handled in an appropriate way. There are proposals to add some sort of exception handling to Fortran to help with this.

Steve

[ronalddavis]

That makes sense. I'll heed your warning and try to think of some other way to prevent nonsense from inadvertently being used as valid data. I need to be inventive, however, because this is in methods of a derived type that can be used in many contexts.

Your basic method proved useful to me in another way. I wanted to write an elemental function that uses FullPathQQ. I think FullPathQQ should be a pure function in its implementation, but your idea enabled me to do what I wanted as it is.