RE: ISSUE-13: [API] Exception codes

The idea of a design pattern to ensure that legacy implementations do
not break as the interfaces are updated sounds like a good idea. We
might be able to include some guidance with the API when it is finally
decided.

It had not occurred to me that the mapping of enums could be more
complex than the typical mapping to integers. There is also no guarantee
that the mapping of an extended enum set would result in the same
assignments for the named members of the original set. I suppose,
therefore, that the "easier" prescription of simple unsigned short codes
would be appealing, especially if accompanied by some guidance on how
they should be managed in implementations.

Thanks for the insight.

---Rotan.


From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Rodrigo Garcia Acevedo
Sent: 13 June 2007 17:42
To: public-ddwg@w3.org
Subject: RE: ISSUE-13: [API] Exception codes

I agree too, updating the API means that we could extend the enum
entries and I also see the enum choice as more 'elegant'.
But I also think that the use of an unsigned short code could be easier
to handle and that it is less likely that a legacy app could break if a
new code is added (probably it would fall in the default section of a
switch). IDL enums don't have an associated ordinal so its
representation changes in the different language mappings (some
languages could map each entry to a class, others directly to a typed
enum, an int...) so maybe its handling would be more difficult.

Anyway, I also wonder whether they would have done the same. The
restriction about the use of exception inheritance is unfortunate.

Regards,
Rodrigo.

Received on Wednesday, 13 June 2007 17:02:30 UTC