Exceptions specifications

Exceptions specifications

Post by Rayiner Hash » Fri, 04 Jul 2003 04:15:51



I have a question about the C++ CORBA mapping. Does the CORBA spec
require server-side skeletons to use exception specifications?

TAO says yes, which means I have to write this:

class foo_impl :public POA_foo
{
    ...
    void bar() throw(CORBA::SystemException);
    ...

Quote:};

OmniORB says no, which means I can write this:

class foo_impl :public POA_foo
{
    ...
    void bar();
    ...

Quote:};

The OmniORB tutorial doesn't use exception specifications either, so I
don't think its a matter of omniidl supressing exception
specifications on my compiler (GCC 3.2.2 on Linux). I could just be
safe and write exception specifications in all cases, but the CORBA
C++ mapping is un-C++ enough as it is, and I'd really like to avoid
using what most C++ texts tell you to avoid.
 
 
 

Exceptions specifications

Post by Douglas C. Schmi » Fri, 04 Jul 2003 05:12:32


Hi Rayiner,

++ I have a question about the C++ CORBA mapping. Does the CORBA spec
++ require server-side skeletons to use exception specifications?
++
++ TAO says yes, which means I have to write this:
++
++ class foo_impl :public POA_foo
++ {
++     ...
++     void bar() throw(CORBA::SystemException);
++     ...
++ };

You needn't do this with TAO, i.e., you can instruct TAO's IDL
compiler to suppress the generation of exception specifications.
Please see the discussion on this point in the TAO options file at

http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/compiler.html

Thanks,

        Doug

++ OmniORB says no, which means I can write this:
++
++ class foo_impl :public POA_foo
++ {
++     ...
++     void bar();
++     ...
++ };
++
++ The OmniORB tutorial doesn't use exception specifications either, so I
++ don't think its a matter of omniidl supressing exception
++ specifications on my compiler (GCC 3.2.2 on Linux). I could just be
++ safe and write exception specifications in all cases, but the CORBA
++ C++ mapping is un-C++ enough as it is, and I'd really like to avoid
++ using what most C++ texts tell you to avoid.

--
Dr. Douglas C. Schmidt, Professor           TEL: (615) 343-8197
Electrical Engineering and Computer Science FAX: (615) 343-7440
Vanderbilt University                       WEB: www.cs.wustl.edu/~schmidt/


 
 
 

Exceptions specifications

Post by Matthias Ries » Fri, 04 Jul 2003 05:25:31



> I have a question about the C++ CORBA mapping. Does the CORBA spec
> require server-side skeletons to use exception specifications?

According to v1.0 of the language mapping: yes.

According to v1.1 of the language mapping released a month ago: no.

Quote:> TAO says yes, which means I have to write this:

> class foo_impl :public POA_foo
> {
>     ...
>     void bar() throw(CORBA::SystemException);
>     ...
> };

> OmniORB says no, which means I can write this:

> class foo_impl :public POA_foo
> {
>     ...
>     void bar();
>     ...
> };

> The OmniORB tutorial doesn't use exception specifications either, so I
> don't think its a matter of omniidl supressing exception
> specifications on my compiler (GCC 3.2.2 on Linux). I could just be
> safe and write exception specifications in all cases, but the CORBA
> C++ mapping is un-C++ enough as it is, and I'd really like to avoid
> using what most C++ texts tell you to avoid.

There are also technical reasons speaking against exception
specifications. An ISO C++ conformant compiler checks exceptions
thrown by the implementation against the exception specification if
present. This results in the unexpected_handler/abort being called if
the implementation throws an exception it isn't declared in the IDL to
throw. However the CORBA standard wants CORBA::UNKNOWN to be passed to
the client in this case. Thus the OMG's decision to change the
language mapping.

With the option -Ge 0 the TAO IDL compiler generates code like this:

void bar() ACE_THROW_SPEC ((CORBA::SystemException));

I suggest you try to override ACE_THROW_SPEC to exclude the exception
specification.

Best regards, Matthias Riese

--
Matthias Riese
Software Engineer
b-novative GmbH Bremen, Germany
Phone,Fax: +49 700 2668 2848
WWW: http://www.b-novative.com

 
 
 

Exceptions specifications

Post by Boris Kolpacko » Sat, 05 Jul 2003 02:06:53



> There are also technical reasons speaking against exception
> specifications. An ISO C++ conformant compiler checks exceptions
> thrown by the implementation against the exception specification if
> present. This results in the unexpected_handler/abort being called if
> the implementation throws an exception it isn't declared in the IDL to
> throw.

If implementation throws unspecified exception then it violates the
contract and calling abort is not necessarily the worse thing to do.

Consider this IDL

interface I
{
   string foo ();

Quote:}

and this implementation of foo in C++:

virtual char*
foo () throw ()
{
   return reinterpret_cast<char*> (0x12345678);

Quote:}

Would you expect orb to throw CORBA::UNKNOWN in this case?

hth,
-boris

 
 
 

Exceptions specifications

Post by Matthias Ries » Sat, 05 Jul 2003 03:05:42




>> There are also technical reasons speaking against exception
>> specifications. An ISO C++ conformant compiler checks exceptions
>> thrown by the implementation against the exception specification if
>> present. This results in the unexpected_handler/abort being called if
>> the implementation throws an exception it isn't declared in the IDL to
>> throw.

> If implementation throws unspecified exception then it violates the
> contract and calling abort is not necessarily the worse thing to do.

In some cases, for example while developing, this may be true. In
some, for example after deployment, not.

It's better to have a standard without a self-contradiction and
software adhering the standard.

Quote:> Consider this IDL

> interface I
> {
>    string foo ();
> }

> and this implementation of foo in C++:

> virtual char*
> foo () throw ()
> {
>    return reinterpret_cast<char*> (0x12345678);
> }

> Would you expect orb to throw CORBA::UNKNOWN in this case?

The above code has undefined behaviour. Anything could happen.
Including CORBA::UNKNOWN to be thrown.

I can't see how this relates to exception specifications.

Quote:> hth,
> -boris

Not really, Matthias
 
 
 

Exceptions specifications

Post by Michi Hennin » Sat, 05 Jul 2003 08:22:58




> > There are also technical reasons speaking against exception
> > specifications. An ISO C++ conformant compiler checks exceptions
> > thrown by the implementation against the exception specification if
> > present. This results in the unexpected_handler/abort being called if
> > the implementation throws an exception it isn't declared in the IDL to
> > throw.

> If implementation throws unspecified exception then it violates the
> contract and calling abort is not necessarily the worse thing to do.

We removed exception specifications mainly because they are are a real
mis-feature:

1) An exception specification does not help the implementer of a
   member function.

   I can write all the exception specifications I like and still call
   anything that might throw anything inside the body of a member
   function. Exception specifications are not statically checked, so if
   my function promises to throw no exceptions at all and I call
   something in the function that might throw, the compiler will not
   pull me up.

2) An exception specification does not help the caller of a member
   function.

   When I see a member function definition with an exception
   specification, I am *not* promised that the function will throw only
   the exceptions listed in the exception specification. Instead, what
   I'm promised is that the function will not throw, will throw one of the
   listed exceptions, or will call unexpected(). In turn, that is no guarantee
   either, because even unexpected() may do unexpected things, such as
   *not* calling abort(), namely, if it has been replaced. (I guess this
   means that unexpected() has been named most aptly... ;-)

3) I cannot prevent the call to unexpected().

   If a function with an exception specification throws an illegal
   exception, I have no way to prevent the call to unexpected(). (Yes, I
   can replace unexpected(), but only once, at global scope, which is
   frowned upon, just as is replacing global operator new.) So, there is
   no way to take corrective action in this case (as would be needed in
   order to correctly throw UNKNOWN for CORBA).

4) Exception specifications subvert the type system in subtle ways.

   Have a look through the last year's issues of CUJ. Herb Sutter wrote
   an interesting example that shows subtle changes in the semantics of
   overload resolution (from memory) that were caused by exception
   specifications. (Sorry, I don't have the issues handy, so I can't
   give a more precise reference.) From memory, Scott Meyers also has a
   few non-complimentary things to say about exception specifications
   (see "More Effective C++").

So, exception specifications are one of the very few true mis-features
in C++ and we decided that we were better off without them.

Cheers,

Michi.

--
Michi Henning                Ph: +61 4 1118-2700
ZeroC, Inc.                  http://www.zeroc.com

 
 
 

Exceptions specifications

Post by Rob » Sat, 05 Jul 2003 09:14:36



Quote:> [Snip]
> Consider this IDL

> interface I
> {
>    string foo ();
> }

> and this implementation of foo in C++:

> virtual char*
> foo () throw ()
> {
>    return reinterpret_cast<char*> (0x12345678);
> }

> Would you expect orb to throw CORBA::UNKNOWN in this case?

No I wouldn't.  In this case, anything could happen because any attempt
(eg within the ORB) to use the pointer returned by foo() [such as copying
the data it points at, which would be sort of required in this case to
return
data to the client] yields undefined behaviour according to the C++
standard.   No ORB can fairly be expected to recover from that, without
using C++ compiler specific features.
 
 
 

1. Is C++ exception specification weak ??

No I m not aiming for a religious war ( moreover I like C++ more than
java )...

I was reading an earlier thread where it said if the servant code raises a
non corba exception, the client should receive a CORBA::UNKNOWN.

While looking at the generated code for idl -poa, I saw that it actually
generates the function signature with exception specification ( throw
clause ).
Now the default action for an exception thrown *other than the ones
declared**, in C++ is to call unexpected() ( which can be set using
set_unexpeced() ), which in turn kills the process with an abort.
So unless the orb runtime, called set_unexpected() when the process was
initialized ( ORB_init() ??? ), there is no was the client can get
CORBA::UNKNOWN since the server will be dead by then.

But then this is indirectly saying that "you can t use the set_unexpected()
feature of C++ while writing a corba server".

Also on previous occasions I ve seen that the generated code did not have
exception specifications ( though I cant remember on what context this
was ).

If the client is to be sent a CORBA::UNKNOWN, the only way I can see (
without restricting the usage of set_unexpected() ) is to generate the stub
without an exception clause, and then the orb's method that invokes the
servant code can catch(... ) ( after checking for all corba exceptions ) and
throw a CORBA::UNKNOWN in the handler for catch(... )

Or maybe I missed something somewhere.

In general is it felt at point of CORBA - C++ mapping, that C++ exception
specification is broken ( like no common base class for the thrown
exceptions )

--sony

2. Firewall suggestion

3. Exception Specifications in C++ mapping

4. MultiTimer by Erik Johansen Series 3

5. Exception Specifications In CORBA Methods

6. CD ON AS/400

7. Algebraic specification languages for real-time system specification

8. TESTERS Wanted for Encryption Program

9. NeXTStation: Exception #3 and Exception #2

10. Exceptions in Interrupt Handlers (Exception Message)

11. CORBA user-defined exceptions as Java _unchecked_ exceptions?

12. exceptions && exception objects

13. Scanner specifications