Re: Trapping run-time errors

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.

Cheers,
Randy


jdujic@xxxxxxxxx wrote:

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)

.

Relevant Pages

  • Re: How to avoid file I/O error when reading files with stringlist
    ... In Delphi, I/O errors cause an exception to be thrown if the particular statement was compiled in the state with I/O checking on. ... exception stack which you can handle if you wish with the general methods, how ever, the Sysutils must be in use so that the exception system is actively operating other wise, compiling with ...
    (comp.lang.pascal.delphi.misc)
  • Re: How to avoid file I/O error when reading files with stringlist
    ... In Delphi, I/O errors cause an exception to be thrown if the particular statement was compiled in the state with I/O checking on. ...
    (comp.lang.pascal.delphi.misc)