[omniORB] bug report

[Stefan Seefeld]

Duncan Grisby wrote:
> 
> On Thursday 16 November, Stefan Seefeld wrote:
> 
> > I added the 'try' block to check, and indeed, it is the client which
> > catches the BAD_PARAM exception:
> >
> >    16.9528:0  enter Viewer::press
> > omniORB: LocateRequest to remote: root<16777216>
> > omniORB: throw BAD_PARAM from giopClient.cc:495
> > got a bad parameter !
> 
> Yes, that is precisely what is meant to happen. The Python servant
> tries to return a bad parameter, so the server-side ORB sends a
> BAD_PARAM exception to the client. The client catches it. I don't
> understand what you think is wrong.

I'm sorry, I should have thought more before posting. My reasoning was
that I couldn't imagine that I have to be prepared on every (potentially remote)
request which involves parameters for that kind of errors. I'm trying to write a 
server which is stable even in the face of buggy (or malicious) clients. 
I would have thought that attempts of the client to communicate 'bad parameters' 
to the server are cought by the ORB, insulating the server's implementation
code completely from such stuff !

However, as I understand now the problem for return values is conceptual.
Even if the client would issue an exception to the server returning a
'bad response', it has to continue somehow, i.e. it can't wait in an endless
loop until the server decides to return a correct result.

Anyway, this now opens up a whole new can of worms, as I have to think about
how to react in this kind of situations...

Thanks a lot, and sorry for the confusion.

Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...