Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

error handling

joseng
Beginner
449 Views
I can't find how to handling the errors in a typical application, like Overflow,
functions domains o math errors, arrays bounds exceeded, and others.
"SIGNALQQ Run-Time Function: Registers the function to be called if an interrupt signal occurs. "
SIGNALQQ can't handling these errros and i want to know if there is a function like SIGNALQQ that I can use.

By the way, I'm programming Win32 Visual Fortran Applications
and this is the best Fortran forum

If you can help me, thanks a lot




0 Kudos
1 Reply
jimdempseyatthecove
Honored Contributor III
449 Views

Array bounds exceeded is best handled before the fact with assertion code. The assertion code can be conditionaly compiled by way of defined variable.

!DEC$ IF DEFINED (AssertBounds)
if((Index .lt. 1) .or. (Index .gt. size(Array)) call ArrayBoundsError('Your message')
!DEC$ ENDIF

Then when debugging have a break point in your ArrayBoundsError subroutine.

For floating point errors you would compile to avoid generating FP interrupts and insert assertion codethat use FP_CLASS on the result. A snip of code from one of my subroutines:

TheNewFPRAT = Expression
JFP_CLASS =
FP_CLASS(TheNewFPRAT)
SELECT CASE (JFP_CLASS)
CASE (0)
! write(*,*) 'TOSSF21 FOR_K_FP_SNAN'
TheNewFPRAT = FPRAT(JTETH1)
CASE(1)
! write(*,*) 'TOSSF21 FOR_K_FP_QNAN'
TheNewFPRAT = FPRAT(JTETH1)
CASE(2)
! write(*,*) 'TOSSF21 FOR_K_FP_POS_INF'
TheNewFPRAT = FPRAT(JTETH1)
CASE(3)
! write(*,*) 'TOSSF21 FOR_K_FP_NEG_INF'
TheNewFPRAT = FPRAT(JTETH1)
CASE(4)
! OK - FOR_K_FP_POS_NORM
CASE(5)
! OK - FOR_K_FP_NEG_NORM
CASE(6)
! write(*,*) 'TOSSF21 FOR_K_FP_POS_DENORM'
TheNewFPRAT = FPRAT(JTETH1)
CASE(7)
! write(*,*) 'TOSSF21 FOR_K_FP_NEG_DENORM'
TheNewFPRAT = FPRAT(JTETH1)
CASE(8)
! OK - FOR_K_FP_POS_ZERO
CASE(9)
! OK - FOR_K_FP_NEG_ZERO ? Saw this with 0. * 9.900990099009901E-003
! ? could have been -0. * 9.900990099009901E-003
CASE DEFAULT
! write(*,*) 'TOSSF21 FOR_K_FP_unknown'
TheNewFPRAT = FPRAT(JTETH1)
END SELECT

The assertion code is typically inserted were you formerly experienced problems. You would initially run with the errors that can generate interrupts to generate the interrupts. Then when you locate trouble spots, inset the FP_CLASS assertioncode and thenrun without generation of error interrupts (by selecting to produce Infinity and Not A Number, etc...)

With the assertion code enabled then you can add debug break points so you can analyze and fix the error in your code. Or, as in the case above fix up the return value to ones you wish to use under the circumstance.

Jim Dempsey

0 Kudos
Reply