Look at the code generated by the java compiler. It uses more of the "optional" features than most (all?) of the others.
On Tue, Apr 20, 2010 at 2:37 PM, Mayan Moudgill <[email protected]> wrote: > > Huh? How can the server determine BAD_SEQUENCE_ID or MISSING_RESULT? > > It would help if there were some place where these exceptions were actually > generated, of course. > > Jonathan Ellis wrote: > >> The are intended to be sent by the server. Look at the error-handling >> code in the client when it does a receive. >> >> On Tue, Apr 20, 2010 at 2:24 PM, Mayan Moudgill <[email protected]> wrote: >> >>> Those appear to be client generated exceptions, not exceptions sent from >>> the >>> server to the client. Basically, they appear to be checks for a bad >>> reply. >>> >>> Jonathan Ellis wrote: >>> >>> >>>> TApplicationException has an enum (of sorts) of different error types. >>>> >>>> On Tue, Apr 20, 2010 at 1:39 PM, Mayan Moudgill <[email protected]> >>>> wrote: >>>> >>>> >>>>> Right now, the mechanism for reporting an error from server to host is >>>>> to >>>>> use T_EXCEPTION messages. However, there don't appear to be any defined >>>>> other than the "unknown RPC" or equivalent. >>>>> >>>>> Is there any proposal to systematically define a set of errors? I can >>>>> think >>>>> of: >>>>> - out-of-memory >>>>> - invalid argument >>>>> - out-of-resources >>>>> just for starters. >>>>> >>>>> Exceptions appear to return a string and an integer. Is this always >>>>> true, >>>>> or >>>>> just an artifact of the current implementation(s)? Do the >>>>> string/integers >>>>> have any semantic content? >>>>> >>>>> Thanks >>>>> >>>>> Mayan >>>>> >>>>> >>>> >>>> >>>> >>> >> >> > >
