Re: Trapping run-time errors
- From: "R. MacDonald" <scitec@xxxxxxxxxxxxxxx>
- Date: Wed, 18 Jan 2006 07:47:43 +0100
Hi, Jugoslav, Arjen,
Thanks for your replies. At least it's good to know what isn't possible/plausible. Fortunately, in this case I need only worry about oversights on the part of the DLL coders, not vindictive nastiness.
As Jugoslav has pointed out, I can trap the Access violations and Array-Out-Of-Bounds. The latter will be more likely for the coders involved, as will FP and unfortunately, the I/O errors that I can't trap. For those I guess I'll just have to provide a "caveat coder" document for those creating/using the DLLs.
Arjen Markus wrote:
If you have little or no control over the DLL, then there is very little you can do: Suppose someone includes a fragment like this:
open( 10, file = 'myfile.inp', status = 'old', iostat = ierr ) if ( ierr .ne. 0 ) then stop endif
I have had trouble with trapping floating-point errors myself. This seems that, at least partly, the operating system has some control over that, beyond and above what the compiler allows you to configure. Again, that leads to the undesirable situation that you can only hope for the best!
As for floating-point errors, I had the reverse problem (I wanted fpe:3 but under Delphi host the code still raised FP exceptions). I solved it by calling GET/SET ControlFpQQ on every entry to dll exports:
call getcontrolfpqq(iFpu) iFp=iFpu.or.FPCW$OVERFLOW.or.FPCW$INVALID.or. & FPCW$ZERODIVIDE.or.FPCW$UNDERFLOW.or.FPCW$INEXACT call setcontrolfpqq(iFp)
As for other run-time errors, except for Access violation and Array out of bounds, which are real exception and thus catchable by SEH, CVF handles most other internally, i.e. it raises no exception but rather displays a &*#$% message box or just calls %#@% ExitProcess. That is true for I/O errors and allocation errors. Finally, I reverse-engineered and wrote my own version of CVF run-time routine for_alloc_allocatable, which falls down to default RTL when successful, but behaves as I want otherwise (instead of changing a zillion ALLOCATE statements to use STAT). That's probably possible for OPEN as well, but the complexity of OPEN makes me scary of plausibility of such project.
-- Jugoslav http://www.xeffort.com (posting from Google groups since my university bureaucrats cut off news:// access)
- Prev by Date: Re: Jumping into block of an if construct
- Next by Date: Re: gcov for fortran
- Previous by thread: Re: Trapping run-time errors
- Next by thread: Re: Trapping run-time errors