SWIG, current gr-howto structure and exception specifiers

GNU Radio
1

In the current state of gr-howto (which is also used in gr_modtool), the
SWIG stuff is done pretty intelligently by using the header files as
.i-files, which means there is no need to write a SWIG header for every
block.

One advantage of this was the possibility to add stuff in the .i-file
which weren’t in the .h-file; specifically, exception specifiers.

Example (from gr-specest, specest_welch.i):

GR_SWIG_BLOCK_MAGIC(specest,welch);

specest_welch_sptr
specest_make_welch(unsigned fft_len, int overlap, int ma_len, bool
fft_shift, const std::vector &window)
throw(std::invalid_argument);

// And so on .

If I don’t declare the exception specifier, I can’t catch the exception
in Python. If I simply include specest_welch.h in specest_swig.i, I need
to add the specifiers in the C+±code, which is not very popular (and I
think not future-compatible, and gcc doesn’t handle that well).

Here’s my question: is there a cool way to have SWIG know about the
exceptions without having to write a .i-file for every block that uses
exceptions? Can I ‘tag’ the source code in a way that gcc doesn’t care,
but SWIG does?

Thanks for any nice ideas!

MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

2

On Fri, May 11, 2012 at 7:03 AM, Martin B. [email protected]
wrote:

GR_SWIG_BLOCK_MAGIC(specest,welch);
to add the specifiers in the C+±code, which is not very popular (and I
think not future-compatible, and gcc doesn’t handle that well).

Here’s my question: is there a cool way to have SWIG know about the
exceptions without having to write a .i-file for every block that uses
exceptions? Can I ‘tag’ the source code in a way that gcc doesn’t care,
but SWIG does?

Thanks for any nice ideas!

MB

Marin,

With the restructuring of the code and implementation style in the
up-coming version 3.7, we are moving in the same direction of just
including .h files in the component’s main swig .i file. For a very
large majority of cases, there is no need for extra code in the .i
file, so this reduces duplication and simplifies a lot.

For those cases where a developer needs to add SWIG-specific things to
an interface file, you can always edit it by hand and include
everything required to make it work. I’m not practiced enough in SWIG
to know this off the top of my head, but I should think that you could
just include the header file and overwrite a specific case as needed.

On the other hand, I thought all standard exceptions were passed
properly through SWIG to Python already. I was under the impression
that if you’re header file declares that it throws, then you can catch
it in Python. If that’s not the case, then we should try to figure out
an easy way to handle that.

Tom

3

On Sun, Jun 03, 2012 at 10:22:14AM -0400, Tom R. wrote:

On the other hand, I thought all standard exceptions were passed
properly through SWIG to Python already. I was under the impression
that if you’re header file declares that it throws, then you can catch
it in Python. If that’s not the case, then we should try to figure out
an easy way to handle that.

Hi Tom and rest,

so, I didn’t do my research properly (partly): Exceptions are caught
by
SWIG, but they always end up as RuntimeErrors, regardless of what the
exception type was in C++.

So, for future reference:
If you throw a std::invalid_argument in a block constructor, it ends
up as a RuntimeError in Python. If you hand-edit the SWIG file and add
an exception specifier, it ends up as a ValueError, which I think is the
better behaviour, and it would be great if SWIG did this automatically.

But frankly, I don’t think this is that big a deal, I’ll just catch
RuntimeErrors instead of ValueErrors. Or edit .i-files.

There’s just no “clean” way to do this, because you’d either have to
specify the exceptions in the header (which is deprecated C++), write a
.i (redundant) or lose the exception type.

MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

4

On Tue, Jun 5, 2012 at 2:58 PM, Martin B. [email protected]
wrote:

SWIG, but they always end up as RuntimeErrors, regardless of what the

There’s just no “clean” way to do this, because you’d either have to
specify the exceptions in the header (which is deprecated C++), write a
.i (redundant) or lose the exception type.

MB

Yeah, I remember looking at this a while ago (since there is still an
error where FreeBSD treats one particular exception incorrectly).
There are a few exceptions that are handled by SWIG, but mostly the
C++ ones just get smashed into one or maybe two different exceptions
in Python.

I’m of the opinion that I agree that it’s not a big deal. An exception
might now be technically incorrect, but I think we can translate as
needed.

Tom