Bug 2064

Summary:	Exceptions in Thru_POA Collocation strategy
Product:	TAO	Reporter:	Nanbor Wang <bala>
Component:	ORB	Assignee:	Johnny Willemsen <jwillemsen>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	P3
Version:	1.4.4
Hardware:	All
OS:	All
Bug Depends on:	1852
Bug Blocks:

Description Nanbor Wang 2005-03-16 04:23:29 CST

This is actually on the main trunk. 

If a servant raises an exception that is not their in the exception throw list,
the client communicating with the collocated object gets the right type of
exception. This AFAICS, is not in compliance with the CORBA spec. The client
should infact receive CORBA::UNKNOWN exception and not the righ texception that
the servant raises in a collocated mode.

Comment 1 Ossama Othman 2005-03-24 13:11:25 CST

Mine.

Comment 2 Johnny Willemsen 2005-08-06 13:59:11 CDT

I have just created a regression for this based on the new collocation test that
QualComm provided. With Borland at least I don't see this problem, when a method
has a raises A and B is thrown the caller nicely gets a unknown system
exception. I will add the regression to the repo when the archive is unfrozen
and we can see if this problem is maybe compiler/platform dependent

Comment 3 Johnny Willemsen 2005-08-08 04:37:35 CDT

Added a regression for this:

        * tests/Collocation_Exception_Test/*:
          New test for testing exceptions in collocated case

Seems this are failing at least in emulated exception case.

Comment 4 Johnny Willemsen 2005-08-11 13:55:16 CDT

things seem to fail with msvc and emulated exceptions

Comment 5 Johnny Willemsen 2005-08-17 04:00:41 CDT

Assigning back to the pool, this seems to be a problem, the regression is in
place but I don't have time right now to fix this.

Comment 6 Johnny Willemsen 2005-08-22 03:43:05 CDT

Bala, looking at bugzilla bug 1852 and the given link there, it looks like the
use case that a servant raises a non specified exception is a programmer issue,
not a TAO issue. If we remove the throw spec the unhandled exception handler we
have in TAO will also not work anymore and then also in the remote case we get
this behaviour.

Comment 7 Johnny Willemsen 2007-01-09 07:36:42 CST

added depends on 1852.

Comment 8 Johnny Willemsen 2007-02-05 14:21:49 CST

[OO] Can we get by with a pair of:

   catch (CORBA::Exception & ex) { ... }
   catch (...) { ... // convert to CORBA::UNKNOWN }

catch blocks in the collocated case?  We could refine the CORBA
exception catch block to blocks for CORBA::SystemException and
CORBA::UserException, and only perform the check against the exception
specified in the IDL raises() clause for the UserException case since
SystemExceptions are always allowed, right?

Comment 9 Johnny Willemsen 2007-02-06 10:28:04 CST

mine

Comment 10 Johnny Willemsen 2007-02-06 13:05:14 CST

fixed