Have fortran throw a VB.NET-catchable exception

[erik2055]

1:
I call LAPACK Fortran routines (in a .DLL, compiled by IVF / VS2008) from my VB.NET program. I want to have VB handle the errors generated by LAPACK. So the LAPACK routines must throw an exception for VB to catch.
Possible ?

2: There is this LAPACK routine named XERBLA that types out the LAPACK error number and a string to the console. That you don't want in Windoze. So, a possibility might be, to have XERBLA call a VB.NET sub that handles the error number and maybe throw an exception. There is some doc on calling VB from Fortran, but I find that very unclear (or maybe too complex ?).
Help appreciated here.

[ArturGuzik]

Quoting - erik2055

1:
I call LAPACK Fortran routines (in a .DLL, compiled by IVF / VS2008) from my VB.NET program. I want to have VB handle the errors generated by LAPACK. So the LAPACK routines must throw an exception for VB to catch.
Possible ?

2: There is this LAPACK routine named XERBLA that types out the LAPACK error number and a string to the console. That you don't want in Windoze. So, a possibility might be, to have XERBLA call a VB.NET sub that handles the error number and maybe throw an exception. There is some doc on calling VB from Fortran, but I find that very unclear (or maybe too complex ?).
Help appreciated here.

Erik,

(1) I might be wrong, but throwing managed code exception from unmanaged code is not something you can do, at least in "normal" way. With LAPACK, I believe, the "hands on" approach would be write a wrapper around your calculation routines (including LAPACK calls) as a standard dll and then: (a) get the LAPACK return flag (b) pass it back to .NET along with string containing error description (c) throw new exception on VB.NET side if errors were detected. The possible run-time errors (crashes) you handle via standard try{}catch{}finally{} construct.

(2) the steps (b) and (c) handle this.

If you desperately need to call managed code from unmanaged (Fortran) code, I think, the easiest (?) way would be generating vb.net with COM interop enabled (which you have to tick on on your compilation page in VS) and then use IVF Module Wizard to create necessary interface.

Others, probably can come up with a nicer solution to that.

A.

[g_f_thomas]

You used to be able to do this in IVF 9, IIRC. For a while you could do it for a static lib but not a dll. Lately you can't do it at all, AFAIK. Very unWindows like. Perhaps this is what is meant by the new Intel Windowing. You can do it in CVF though, it hasn't been fixed and there's a good chance that it wont.

Gerry