Exception handling under IVF

[longden_loo]

Well, I got my __try/__except exception handling working the way I wanted on CVF, but when I tried the code under IVF, a test array-out-of-bounds condition generated a stack trace and aborted the program instead of returning control to the program.

I modified the __except to force a program continuation ...

__try {
fortran_driver();
__except ( 1 )
{
* stuff that's supposed to happen, but doesn't *
}

... but the except clause never seems to execute (program just aborts). For the C wrapper project, I have "Enable C++ Exceptions" set to "yes", and "Basic Runtime Checks" set to "Both", without any effect.

I noticed that on the same project in CVF where the exception is being handled correctly, there's a project setting for C/C++ | C++ Language | Enable exception handling ... and that item is enabled ... but I can't find the equivalent in IVF.

Anyone have a clue? Thx.

[drgfthomas]

I use IVF 9.1/VS.NET 2003/Windows 2000.

I downloaded your .zip, built sehtest.sln. I've attached a modified new .zip.

The changes I made are:

1. Changed the calling convention to 'Default' (not that it matters)

2. Altered the SEH main.cso that it catches the BreakPointexception spawned by the array out of bounds exception.

Open sehtest.sln in VS go to Debug/Start, it will ask you to rebuild, do so, the severe error pops up due to the array out of bounds whereupon an unhandled breakpoint exception is raised and the show is over. But wait, go to Debug/Start Without Debugging, the severe error shows again followed by the execution of your new SEH which cataches the breakpoint. Simply marvellous!

HTH

[longden_loo]

I posted a reply and it seemed to have gotten lost...

[longden_loo]

Thanks Gerry for that investigation and tip ... and thanks also to Jugoslav and Steve for those insights into array bounds error handling (although like Gerry, I'll confess that my eyes glazed over on the details).

Unfortunately, my IVF 9.0 wasn't able to open your newSEHTEST solution (complained about projects being created from a newer version), but I was able to duplicate your results using my original test sample. So within the IDE, SEH appears to work outside the debugger, but not inside the debugger ... which is both "marvellous" and unsettling at once.

To make things more complicated, I ran the completed driver.exe in a command window (outside the IDE) where it aborted without trapping the array error (evidenced by the lack of the printf message in the console window). Gerry, can you confirm that happens for you too? Thx again.

- Longden

[drgfthomas]

Longden,

Yes, that's right. Of course one ought to fix array out of bounds on the spot so I don't have a problem with IVF on that score. However, this is in contrast to VC whichcatches such exceptions. For mixed language (C++/IVF)use, I'd like to see greater inter language consistency within a VS solution.

Here's a C++ sample that catches sundry exceptions including array out of bounds.

// Entry point for the console application

#include "stdafx.h"
#include 
using namespace std;

//extern void Sample();

void main()
{
int x, y;
int *ptr, a[2], a1;

cout << "Beckett's maxim:" << endl;
cout << "'Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.'
";

__try 
{
x = 5;
y = 0;
x = x / y;
}
__except (GetExceptionCode() == EXCEPTION_INT_DIVIDE_BY_ZERO ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH){

cout << "Divide by zero error." << endl;
}
__try 
{
x = INT_MIN;
y = -1;
x = x / y;
}
__except (GetExceptionCode() == EXCEPTION_INT_OVERFLOW ? EXCEPTION_EXECUTE_HANDLER :EXCEPTION_CONTINUE_SEARCH) {

cout << "Integer overflow during division." << endl;
}
__try {
x = INT_MAX;
x++;

cout << "Integer overflow during increment." << endl;
}
__except (GetExceptionCode() == EXCEPTION_INT_OVERFLOW ? EXCEPTION_EXECUTE_HANDLER :EXCEPTION_CONTINUE_SEARCH)
{
}
__try 
{
//Sample();
}
__except (GetExceptionCode() == EXCEPTION_INT_OVERFLOW ? EXCEPTION_EXECUTE_HANDLER :EXCEPTION_CONTINUE_SEARCH)
{

}
__try {
ptr = a;
a1 = 3[ptr];
cout << "Array out of bounds." << endl;
}
__except (GetExceptionCode() == EXCEPTION_ARRAY_BOUNDS_EXCEEDED)
{
}
} // main

// stdafx.h : include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
//

#pragma once

// TODO: reference additional headers your program requires here

#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

[drgfthomas]

Longden,

As post script to my previous message and to close the issue for me,

there follows a rewrite of sehtest that spots the array out of bounds, in

and out of the debugger (you'd use TRACEBACKQQ in a real sample to

located the line in code where the problem arises) withouttriggering IVF's

intervation:

!arraytest.f90

REAL(4)

FUNCTION ARRAYTEST(R1)

use kernel32

implicit none

INTEGER, intent(in) :: R1

REAL(4) anum(2)

integer u, l

l = lbound(anum,1)

u = ubound(anum,1)

! Cause an array bounds exception

if (R1 < l .or. R1 > u) then

call RaiseException(EXCEPTION_ARRAY_BOUNDS_EXCEEDED, 0, 0, 0)

else

ARRAYTEST = anum(r1)

endif

END FUNCTION

//main.c

#include 
#include 
#include 
#include 
#include 
extern float ARRAYTEST ( int *) ;
void main()
{float a;int b = 0;// Cause an array out of bounds error__try 
{__try 
{
a = ARRAYTEST ( &b ) ; 
}__except (GetExceptionCode() == EXCEPTION_ARRAY_BOUNDS_EXCEEDED)
{
printf("Array out of bounds caught.
");
}
}__finally
{
printf(" 
");
} 
}

This editor is acting up the width is endless and the tools

are not stacked. Hope it shows OK.

[longden_loo]

Yes, I think this closes the issue for me too. Sorry for being late in replying but I've been out of touch for a few days.

My main problem at this point is something I share with the poster in the thread "Using a Fortan DLL in VB that has a STOP command", only instead of worrying about the STOPs, I have a variety of exceptions I'm trying to trap in a huge Fortran legacy app converted to a DLL ... and the aim of the trap is so these violations can be noted (for fixing) while not bringing down the main Java process ... so the user can continue to use other services from the Java GUI. Like a car, sometimes there are functions like the air conditioning and interior lights whose malfunction shouldn't be allowed to disable the ignition.

While a complete general rewrite of the Fortran legacy app is probably in order (as with the DLL with the STOPs problem), we all know the kinds of budget and deadline constraints that often make that a wishful solution.

As the main package is currently delivered with the legacy app compiled in CVF (which captures the array exceptions without code modification), there's no immediate need for an IVF solution (which doesn't).

The unfortunate thing is that while it takes some pressure off me, it also makes IVF a tougher sell to the CVF people resisting the move to IVF.

Thanks again for all the valuable input, testing time and examples!

- Longden