Uploaded image for project: 'Thrift'
  1. Thrift
  2. THRIFT-4562

Calling wrong exception CTOR leads to "call failed: unknown result" instead of the real exception being thrown

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.12.0
    • Component/s: Delphi - Compiler
    • Labels:
      None
    • Patch Info:
      Patch Available

      Description

      Problem

      1. In contrast to other languages, there is no real way to prevent Delphi from inheriting unwanted CTORs.
      2. The generated code initializes an "exception factory" helper object used for serializing the exception info over the wire. This helper object is instantiated in two cases:
        • a) in the CTORs that are defined in the exception class
        • b) when a property setter is called on that instance

      Example

      The following IDL:

      exception ApiException {
       1: string     Msg
       2: i32  Error
      }
      

      results in this Delphi code:

      TApiException = class(TException)
      // ... some unrelevant details omitted ...
      public
        constructor Create; overload;
        constructor Create( const AMsg: System.string; AError: System.Integer); overload;
        // ... more code ...
      end; 
      

      Due to the inheritance from TException and finally System.Exception, a bunch of other CTORs is inherited, such as:

        constructor Create(const Msg: string);
      

      From this, a situation may arise, in which the developer instantiates the instance by calling one of the inherited CTORs (which do not intialize the Factory helper object), then raising the exception without assigning any other values via property setter:

      raise TApiException.Create('some error occurred!');  // inherited CTOR
      

      instead of

      raise TApiException.Create('some error occurred!', 42);  // TApiException  CTOR
      

      Under these circumstances, the Factory helper object is left at its default value of nil, hence no suitable information is written to the wire. As a direct result, being unable to deserialize anything useful on return, the client code will run into the default catcher code which raises an generic TApplicationException with MissingResult code and the "call failed: unknown result" message.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jensg Jens Geyer
                Reporter:
                jensg Jens Geyer
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: