[omniORB] bug report

[Duncan Grisby]

On Thursday 16 November, Stefan Seefeld wrote:

> Right. The problem here seems that I write one application in a
> statically typed language, which is pretty comforting, while the
> other side is scripted. This whole location transparency now makes
> it appear as a single huge application, so it clearly isn't
> statically typed any more (at least not in the original sense, which
> implied that type errors are caught at compile time).

There is indeed more risk of runtime errors when you implement servers
with a language like Python. However, having a strongly typed language
doesn't completely remove the possibility for runtime errors which
cause exceptions. Consider, for example:

  interface Foo {
    typedef sequence <long> longs;
    typedef string<5> bstring;

    longs   op1();
    bstring op2();
  };

Now you implement it in C++...

  Foo::longs* Foo_i::op1() {
    Foo::longs_var l(new Foo::longs(1));
    l[0] = 1;
    return l._retn();
  }

  char* Foo_i::op2() {
    return CORBA::string_dup("Hello there");
  };


Both of those method implementations have bugs in them. op1() doesn't
set the length of the sequence, so the assignment l[0] = 1 throws
BAD_PARAM. Surrounding the function body in a try block could catch
that error before it propagated to the client.

op2() sends a string which is too long for the bound. That can't be
detected before the method returns. BAD_PARAM will be thrown by the
marshalling code, and there's nothing the server can do to stop it.

Basically, as Gary says, you always have to be prepared to receive
system exceptions when you invoke operations, no matter what you are
doing or how you are doing it.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --