Exception catching f90wrap_error_abort about f90wrap HOT 5 OPEN

So what's your approach?

I use the fexception project which I wrote, available on GitHub:

https://github.com/citibob/fexception

With this, I can throw exceptions in Fortran code and catch them in Python
code.

-- Bob

On Fri, Dec 11, 2015 at 2:59 PM, Mahé Perrette [email protected]
wrote:

Hi James,

Great project, much potential to solve common annoyances when wrapping
modern *f90 code. Both type-passing (f90wrap) and Exception catching are
very useful features, actuallly all of f2py-f90wrap are useful !

When testing it out though, exception catching did not work as smoothly as
hoped: just calling stop did crash the fortran program, as with f2py.
Calling f90wrap_error_abort or even quippy_error_abort (as grepped in
f90wrap/patch_f2py) did not help either ...

So what's your approach?

Thanks again.

—
Reply to this email directly or view it on GitHub
#36.

from f90wrap.

The default is actually f90wrap_abort. You can override the name of a function called on aborts with the -a command line option to f90wrap.

Thanks for spotting the defunct reference to quippy_error_abort in patch, I've updated that to fix this.

from f90wrap.

I just looked at this in slightly more detail, and it appears you can't currently change the abort routine name- it works if you trigger exceptions from Fortran with call f90wrap_abort("error message"), but not if you change the name with the -a argument as the abort function is currently hard-coded in f2py-f90wrap.

I'll leave this issue open to mark the problem - pull requests welcome!

from f90wrap.

Nice !! Many thanks. Sure changing the name would be fine (consistent with the docs...), but for now it is a reasonable workaround to have raise_exception defined somewhere (as it is the case in my code currently) to perform call f90wrap_abort("error message") or stop("error message) depending on whether it is used standalone or from f90wrap.

You did a fine work with this package. I can see how this will change a couple of things for the better in a research workflow involving model development. You might hear from me soon. Pull requests upon need. Cheers.

from f90wrap.

Note that in gfortran (v5.4.0) -fcheck=recursion (implied by -fcheck=all) must be deactivated otherwise a Fortran Runtime error occurs on the subsequent call: Fortran runtime error: Recursive call to nonrecursive procedure ...
Workaround: when debugging instead of -fcheck=all I use all but "recursion": -fcheck=array-temps,bounds,do,mem,pointer.

from f90wrap.