warnings when using directors with multiple throw specifiers

I have some virtual classes with throw specifiers that indicate 
multiple possible exceptions, such as this one:

virtual void fromAdmin( const Message&, const SessionID& )
  throw( FieldNotFound&, IncorrectDataFormat&, IncorrectTagValue&, 
RejectLogon& ) = 0;

The code that is generated looks like this (for python):

            try {
                (arg1)->fromAdmin((FIX::Message const 
&)*arg2,(FIX::SessionID const &)*arg3);
            }
            catch(...) {
                throw;
            }
            catch(...) {
                throw;
            }
            catch(...) {
                throw;
            }
            catch(...) {
                throw;
            }

Now this does not cause any errors (at least not in gcc 3.2, I can't 
speak for other compilers), but it does cause several warnings (since 
... should be the last thing to be caught, and three of them are not 
last).  With multiple directors which can have several methods like 
this, the warnings can add up.  Of course this can make errors more 
difficult to spot.  I would suggest that the generated code either look 
like so:

            try {
                (arg1)->fromAdmin((FIX::Message const 
&)*arg2,(FIX::SessionID const &)*arg3);
            }
            catch(FieldNotFound&) {
                throw;
            }
            catch(IncorrectDataFormat&) {
                throw;
            }
            catch(IncorrectTagValue&) {
                throw;
            }
            catch(RejectLogon&) {
                throw;
            }

or just simply consolidated into:

            try {
                (arg1)->fromAdmin((FIX::Message const 
&)*arg2,(FIX::SessionID const &)*arg3);
            }
            catch(...) {
                throw;
            }

On May 28, 2004, at 12:21 PM, David Beazley wrote:

> Marcelo Matus writes:
> > Ok, the thing is that "C arrays mapping" is a strange case.
> >
> > The problem with C arrays is that the have a known size, and
> > the '\0' ending char is just a coincidence, ie you can define
> >
> >   char hi_a [] = {'h','e','l','l','o'};
> >   char hi_b [] = "hello";
> >
> > and both will be different
> >
> >   sizeof(hi_a) -> 5
> >   sizeof(hi_b) -> 6
> >   strlen(hi_a) -> undefined
> >   strlen(hi_b) -> 5
> >
> > and in the python side you will get
> >
> >   hi_a -> 'hello'
> >   hi_b -> 'hello\0'
> >
> > note that you can also put '0' char in between
> >
> >   char hi_a [] = {'h','e',0,'l','o'};
> >
> >   sizeof(hi_a) -> 5
> >   strlen(hi_a) -> 2
> >
> > So, in your case, maybe is better to use
> >
> >   const char* const BeginString_FIX44 = "FIX.4.4";
> >
> > since that will be properly understood in C,C++ and in the python side
> > (and you don't need the std::string). In that case the use of 'strlen'
> > is explicit, and in the python side you will not see the '\0' ending
> > character.
>
> Any definitions of the form
>
>    char foo[N] = "whatever";
>    char bar[] = "whatever";
>
> should *always* be treated as NULL-terminated strings by default in
> SWIG.    If someone wants different behavior than that, they should
> write their own typemap to do it.
>
> Why is this suddenly broken?  I thought issues concerning C character
> arrays were resolved long ago.
>
> -- Dave

_______________________________________________
Swig maillist  -  Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig