Issue 1963: WrongTransaction vs WRONG_TRANSACTION (ots-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The latest OTS spec (formal/98-07-09) has this exception as WRONG_TRANSACTION, while the CORBA 2.2 and draft CORBA 2.3 documents have WrongTransaction. Which one is right, and is it a system exception, as implied by the OTS, or a user exception as implied by CORBA 2.2? Resolution: This issue has been closed without action. See the discussion section for an explanation. Revised Text: Actions taken: September 16, 1998: received issue August 19, 1999: moved from core to ots rtf January 16, 2001: closed issue Discussion: The OTS spec will be changed by the AB/PTC to reflect that WrongTransaction is a user exception and that WRONG_TRANSACTION does not exist as a system exception. (It is only intended that WrongTransaction be raised by the get_response and get_next_response operations on the ORB.) Since this issue is the same as the core issue 557, this issue will be closed without action by the OTS RTF. End of Annotations:===== Return-Path: Sender: jon@floorboard.com Date: Wed, 16 Sep 1998 08:58:04 -0700 From: Jonathan Biggar To: orb_revision@omg.org Subject: WrongTransaction vs WRONG_TRANSACTION The latest OTS spec (formal/98-07-09) has this exception as WRONG_TRANSACTION, while the CORBA 2.2 and draft CORBA 2.3 documents have WrongTransaction. Which one is right, and is it a system exception, as implied by the OTS, or a user exception as implied by CORBA 2.2? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Wed, 18 Nov 1998 08:28:46 +1000 (EST) From: Michi Henning To: issues@omg.org, orb_revision@omg.org Subject: WRONG_TRANSACTION Organization: Triodia Technologies Hi, 97-12-01 says: WRONG_TRANSACTION Exception The CosTransactions module adds the WRONG_TRANSACTION exception that can be raised by the ORB when returning the response to a deferred synchronous request. This exception is defined in Chapter 4 of the Common Object Request Broker: Architecture and Specification. Two problems here: - This para doesn't state what module is to be used for WRONG_TRANSACTION. I assume what is meant is that it should be a system exception? - I can't find this exception in either chapter 4 or chapter 3 of the 2.3 spec. Looks like it needs to be added. I don't know why the above para refers to chapter 4 though -- it seems that this exception should be added to the list of system exceptions in chapter 3? Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: Sender: jis@fpk.hp.com Date: Wed, 18 Nov 1998 10:48:43 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Michi Henning CC: orb_revision@omg.org, Juergen Boldt , ed.cobb@beasys.com Subject: Issue 2218 References: Michi Henning wrote: > > Hi, > > 97-12-01 says: > > WRONG_TRANSACTION Exception > > The CosTransactions module adds the WRONG_TRANSACTION > exception > that can be raised by the ORB when returning the response to > a > deferred synchronous request. This exception is defined in > Chapter 4 > of the Common Object Request Broker: Architecture and > Specification. The Cos Transaction module doesn't do anything of the sort! The WrongTransaction exception is defined in CORBA module and it is not a Standard Exception and hence not defined in Chapter 3. > > Two problems here: > > - This para doesn't state what module is to be used for > WRONG_TRANSACTION. I assume what is meant is that it should be > a system exception? It should not be a Standard Exception. Only get_response is said to raise this exception. What is Joe User supposed to do if s/he gets this exception? It is nothing that they did that could cause this to happen. It occurs due to some goofup within the ORB. > - I can't find this exception in either chapter 4 or chapter 3 > of the 2.3 spec. Looks like it needs to be added. I don't know > why the above para refers to chapter 4 though -- it seems that > this exception should be added to the list of system exceptions > in chapter 3? > No, Chapter 7 actually, and it is already there - see in the top para of the page on page 7-11 of ptc/98-10-07. The name of the exception is WrongTransaction. It is said to be defined in the CORBA module in section 7.1 of the same document. The IDL in section 7.2 also shows that get_response raises this exception. BTW, the reason that it is called WrongTransaction and not WRONG_TRANSACTION is because it is *not* a standard exception. This was discussed at length in 97 when the OTS revision was taking place. Consequently, it is not the Core that needs fixing but it is the Transaction Service that needs fixing. Juergen, please transfer this issue to the Transaction Service RTF. Better still merge this issue with issue 1963 (i.e. transfer the text from Issue 2218 to Issue 1963 and close Issue 2218), and transfer Issue 1963 with all this annotation to Transaction Service RTF. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: Sender: jis@fpk.hp.com Date: Wed, 18 Nov 1998 15:33:31 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: orb_revision@omg.org CC: Michi Henning , ed.cobb@beasys.com Subject: Issue 1963 [was Re: Issue 2218] References: <3652EC5B.F1F6EF1E@fpk.hp.com> It has been pointed out to me privately by Bob Bukura that the terminology about exceptions that I used is somewhat confusing and plain inaccurate, so this message is to clarify what I meant. Jishnu Mukerji said: > Michi Henning said: > > Two problems here: > > > > - This para doesn't state what module is to be used for > > WRONG_TRANSACTION. I assume what is meant is that it > should be > > a system exception? > > It should not be a Standard Exception. What I meant to say is that it is a Standard *User* exception and not a Standard *System* exception. Standard System Exceptions are the ones that are defined in Chapter 3, and those are the ones that cannot be listed in the raises clause of an operation declaration. Jishnu Mukerji said: > Only get_response is said to raise this exception. > What is Joe User supposed to do if s/he gets this > exception? It is nothing that they did that could cause this to > happen. > It occurs due to some goofup within the ORB. In the statement above, Joe User is the one who is jsut doing an invocation of a random operation (in particular not get_reponse). Jishnu Mukerji said: > BTW, the reason that it is called WrongTransaction and not > WRONG_TRANSACTION is because it is *not* a standard exception. This > was > discussed at length in 97 when the OTS revision was taking place. Rephrase that first sentence to read: BTW, the reason that it is called WrongTransaction and not WRONG_TRANSACTION is because it is not a system exception. It is a user exception. To quote Bob on the matter of definitions of the relevant terms: Bob Kukura said: > system exception - can be raised by any operation, not declared in > raises clause in IDL > user exception - can only be raised if declared in IDL raises clause > standard system exception - system exception defined in CORBA > standard Add to that: Standard User Exception - user exception that appears as a part of a standard. Bob Kukura says further: > > The notion of non-standard system exception exists because vendors > might > add proprietary system exceptions, or an old ORB client might > interoperate with a server implementing a newer CORBA version that > adds > new standard system exceptions not known to the old ORB. System > exceptions not known to the client ORB get raised to the application > as > the UNKNOWN standard system exception. > Sorry about the confusion. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: Date: Thu, 19 Nov 1998 06:46:54 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: orb_revision@omg.org, Juergen Boldt , ed.cobb@beasys.com Subject: Re: Issue 2218 Organization: Triodia Technologies On Wed, 18 Nov 1998, Jishnu Mukerji wrote: > Consequently, it is not the Core that needs fixing but it is the > Transaction Service that needs fixing. Jishnu, thanks for the clarification. I looked wide and far for that exception, but obviously not in the right place... Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: Date: Wed, 18 Nov 1998 14:03:56 PST Sender: Bill Janssen From: Bill Janssen To: orb_revision@omg.org, Jishnu Mukerji Subject: Re: Issue 1963 [was Re: Issue 2218] CC: Michi Henning , ed.cobb@beasys.com References: <3652EC5B.F1F6EF1E@fpk.hp.com> <36532F1B.C45FB3D5@fpk.hp.com> Standard vs. System. Where is this defined? The ambiguity between which of the two the CORBA exceptions are has always bothered me. I'd push for: Standard: exceptions with well-defined meanings that may be raised by any code, system or user, and may be raised from an IDL method even when not defined in the RAISES clause of the method definition. Naturally, there should be as few of these as possible. System: exceptions reserved to the ORB implementation to raise. These should not be raisable from user code. System exceptions may be standard, but need not be. Bill Return-Path: Sender: jon@floorboard.com Date: Wed, 18 Nov 1998 14:48:24 -0800 From: Jonathan Biggar X-Accept-Language: en To: Bill Janssen CC: orb_revision@omg.org, Jishnu Mukerji , Michi Henning , ed.cobb@beasys.com Subject: Re: Issue 1963 [was Re: Issue 2218] References: <3652EC5B.F1F6EF1E@fpk.hp.com> <36532F1B.C45FB3D5@fpk.hp.com> Bill Janssen wrote: > > Standard vs. System. Where is this defined? The ambiguity between > which of the two the CORBA exceptions are has always bothered me. > > I'd push for: > > Standard: exceptions with well-defined meanings that may be raised > by > any code, system or user, and may be raised from an IDL method even > when > not defined in the RAISES clause of the method definition. > Naturally, > there should be as few of these as possible. > > System: exceptions reserved to the ORB implementation to raise. > These > should not be raisable from user code. System exceptions may be > standard, but need not be. Unfortunately, the CORBA 2.2 spec in chapter 3 uses both "standard" and "system" to refer to these exceptions. It appears to use "standard" more, however. Also unfortunately, the C++ language mapping uses SystemException, so we appear to be stuck with both of these meaning exactly the same thing. I am going to post a separate issue for the CORE RTF to consider cleanup on this. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Thu, 19 Nov 1998 09:17:58 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Bill Janssen , orb_revision@omg.org, Jishnu Mukerji , ed.cobb@beasys.com Subject: Re: Issue 1963 [was Re: Issue 2218] Organization: Triodia Technologies On Wed, 18 Nov 1998, Jonathan Biggar wrote: > Unfortunately, the CORBA 2.2 spec in chapter 3 uses both "standard" and > "system" to refer to these exceptions. It appears to use "standard" > more, however. Also unfortunately, the C++ language mapping uses > SystemException, so we appear to be stuck with both of these meaning > exactly the same thing. > > I am going to post a separate issue for the CORE RTF to consider cleanup > on this. Nice idea. This has bugged me for some time too. I think it used to be "system exception" everywhere, and sometime around 2.1 I think, I started noticing the "standard exception" terminology. I think we should use "system exception" uniformly for the exceptions defined in chapter 3. "Standard exception" could be dropped altogether, or it could refer to those user exceptions that are defined in by an official OMG spec. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: Date: Wed, 18 Nov 1998 21:04:59 -0500 From: Bob Kukura Organization: IONA Technologies To: Michi Henning CC: Jonathan Biggar , Bill Janssen , orb_revision@omg.org, Jishnu Mukerji , ed.cobb@beasys.com Subject: Re: Issue 1963 [was Re: Issue 2218] References: I remember this being discussed at an ORB RTF meeting a year or two back. I thought the consensus then was something like the follows: system exception - can be raised by any operation, not declared in IDL raises clause, C++ mapping derived from CORBA::SystemException, structurally equivalent to all other system exceptions user exception - can only be raised if declared in IDL raises clause, C++ mapping derived from CORBA::UserException, structure varies standard system exception - system exception that is defined in the CORBA standard The notion of non-standard system exception exists because vendors might add proprietary system exceptions, and also because an old ORB client might interoperate with a server implementing a newer CORBA version that adds new standard system exceptions not known to the old ORB. System exceptions not known to the client ORB get raised to the application as the UNKNOWN standard system exception. The WrongTransaction exception and any other user exceptions defined in CORBA could be referred to as standard user exceptions. I believe the ORB RTF that discussed this did change some text, probably from "standard exception" to "standard system exception" or "system exception". -Bob Michi Henning wrote: > > On Wed, 18 Nov 1998, Jonathan Biggar wrote: > > > Unfortunately, the CORBA 2.2 spec in chapter 3 uses both > "standard" and > > "system" to refer to these exceptions. It appears to use > "standard" > > more, however. Also unfortunately, the C++ language mapping uses > > SystemException, so we appear to be stuck with both of these > meaning > > exactly the same thing. > > > > I am going to post a separate issue for the CORE RTF to consider > cleanup > > on this. > > Nice idea. This has bugged me for some time too. I think it used to > be > "system exception" everywhere, and sometime around 2.1 I think, I > started > noticing the "standard exception" terminology. > > I think we should use "system exception" uniformly for the > exceptions > defined in chapter 3. "Standard exception" could be dropped > altogether, > or it could refer to those user exceptions that are defined in by an > official OMG spec. > > Cheers, > > > Michi. > -- > Michi Henning +61 7 3236 1633 > Triodia Technologies +61 4 1118 2700 (mobile) > PO Box 372 +61 7 3211 0047 (fax) > Annerley 4103 michi@triodia.com > AUSTRALIA > http://www.triodia.com/staff/michi-henning.html