Error trapping

[Chris Wilson]

When compiling Fortran code to a dll, it appears that any runtime error in the dll generates the following message in the calling VB.Net program:

Unable to load DLL 'testFortran.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

For example, if I force a real number overflow, I get that error (it has nothing to do with being unable to find the dll). Is there any way to handle runtime errors via code in the dll like you could in MS Fortran? Alternatively, would it be possible to somehow attach to stdout and maybe see any runtime errors?

[Chris Wilson]

I'd really appreciate some advice on this topic. Consider the following situation:

Fortran code does some work and I purposely turn on bounds checking and assign to an out-of-bounds item. When compiled as a stand-alone EXE, I get an error on the screen that makes sense.

If I slightly modify the code (remove the Program and add StdCall) and recompile as DLL, then call the same routine from VB.Net, the same error causes my VB.Net application to just stop, with no warning. I have the call to the Fortran app in a separate thread, but still I am not able to trap the error. (The calls to the DLL work fine when I don't force the error in the Fortran code, so VB.Net is communicating nicely with the DLL).

Even if I can't get any really useful information back from the Fortran DLL about why it crashed, I still want to prevent my UI from dying.

I read in the manual about trapping IEEE errors, but that doesn't seem practical for the entire application, and doesn't handle all types of runtime errors.

Can someone please advise me?

Thanks

Chris

[Mike Linacre]

Chris, your situation suggests that a .dll is not suited to your application. Why not compile the routine as a .exe, shell out to it, and then wait for the .exe to complete. If the shelled .exe fails, it won't crash the calling module. Your module could exchange information with the shelled .exe in various ways. If there is a lot of information, a disk work file is effective. Otherwise there are command-line arguments or sending messages.