Re: Trapping run-time errors
- From: "R. MacDonald" <scitec@xxxxxxxxxxxxxxx>
- Date: Thu, 12 Jan 2006 13:43:27 +0100
Hello, Arjen,
Thanks for your reply.
I know about using IOSTAT for I/O errors and have been experimenting with SIGNALQQ for other types of errors.* (I haven't been able to find a SIGNALQQ error code that corresponds to I/O errors to allow me to trap these outside of the routine causing them.)
Anyway, the "real" problem is that I have only very limited control over the code in the DLLs. For example, I can provide "initialization" and "termination" routines that I can insist be used, but everything else that happens is up to others. So, for example, I have no way to ensure that IOSTAT is used (and checked) to guarantee there are no I/O errors during run-time. Ditto with any other type of run-time error.
When there is a run-time error in a DLL routine, I want my application to terminate processing of only that DLL routine (ideally reporting an error message to the user) and then continue. Catching the DLL generated error in the VB.Net application would be perfect, but I haven't yet been able to find any way to do this.
Cheers, Randy
* - As a side problem, I haven't yet figured out how to persuade DVF to generate floating point errors that allow me to test my handling of these. It seems to ignore my setting for "Floating Point Exception Handling" in project settings and returns an Infinity for divide by zero whether this is set to 0 or 3? Of course, there is always RAISEQQ, but this seems artificial and doesn't appear to allow me to simulate different types of fp errors.)
Arjen Markus wrote:
It depends on the kind of run-time errors your DLL is expected to produce: - Errors involving I/O (either internal or external) can be caught with IOSTAT= and a proper examination of what caused this error.
- Errors involving memory allocation can likewise be caught with STAT=
- Errors involving division by zero or other such stuff can be caught (suppressed) only by platform-dependent means. DVF (CVF) offers several routines to do this: SIGNALQQ and MATHERRQQ might be the things you are after.
- Programming errors, like violations of array bounds and such, are likely to be catchable with similar platform-dependent means. I have never tried those though, but I guess the QQ family of routines will enable you to do this.
Regards,
Arjen
.
- Follow-Ups:
- Re: Trapping run-time errors
- From: Arjen Markus
- Re: Trapping run-time errors
- References:
- Trapping run-time errors
- From: R. MacDonald
- Re: Trapping run-time errors
- From: Arjen Markus
- Trapping run-time errors
- Prev by Date: Re: fast matrix multiplication
- Next by Date: Calling Matlab from G95 code
- Previous by thread: Re: Trapping run-time errors
- Next by thread: Re: Trapping run-time errors
- Index(es):