Uploaded image for project: 'Couchbase .NET client library'
  1. Couchbase .NET client library
  2. NCBC-10

Need ability to get error code from Enyim client library

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.1.5
    • Component/s: library
    • Labels:
      None

      Description

      The current library only returns true or false for requests, but some operations provide more information for "false" such as "key not found", "timeout", other error...

      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        john John Zablocki (Inactive) added a comment -

        I'm currently exploring options for updating the client to support better error info. It's a non-trivial effort.

        One approach would be to leave the Boolean response in place and provide an optional callback parameter for API methods. The callback would provide information about an operation's failure. The challenge here is that the call chain for API methods is pretty deep. For example, updating Store to include an optional callback parameter means updating 4 or 5 method signatures and updating 1 or 2 interface definitions. Multiply that number by each operation and the change becomes quite significant.

        The basic pattern is that bool Get calls bool TryGet which calls bool PerformTryGetAndTouch which calls bool ExecuteWithRedirect. Along the way, there are operation factories and other classes that would need the argument passed around. Exceptions are raised and swallowed throughout the call chain. I think an optional callback is the right way to go, but it will a) be a significant dev and testing effort b) require updating Enyim.Caching, not just Couchbase and c) require an upgrade to 4.0 (which I think is right anyway)

        Another approach is to create some sort of server context object that keeps a stack of errors and provides methods for getting the last n errors and events that will be raised when errors occur. This approach is similar to an ASP.NET application where the Server object provides a GetLastError method and there are global events for error handling. It's obviously a disconnected approach that doesn't really give any guarantee about the relationship to errors and operations. It's a best guess... This is easiest to implement and doesn't require changing the API. But it's obviously suboptimal. It's really a programatic hook into logging...

        Show
        john John Zablocki (Inactive) added a comment - I'm currently exploring options for updating the client to support better error info. It's a non-trivial effort. One approach would be to leave the Boolean response in place and provide an optional callback parameter for API methods. The callback would provide information about an operation's failure. The challenge here is that the call chain for API methods is pretty deep. For example, updating Store to include an optional callback parameter means updating 4 or 5 method signatures and updating 1 or 2 interface definitions. Multiply that number by each operation and the change becomes quite significant. The basic pattern is that bool Get calls bool TryGet which calls bool PerformTryGetAndTouch which calls bool ExecuteWithRedirect. Along the way, there are operation factories and other classes that would need the argument passed around. Exceptions are raised and swallowed throughout the call chain. I think an optional callback is the right way to go, but it will a) be a significant dev and testing effort b) require updating Enyim.Caching, not just Couchbase and c) require an upgrade to 4.0 (which I think is right anyway) Another approach is to create some sort of server context object that keeps a stack of errors and provides methods for getting the last n errors and events that will be raised when errors occur. This approach is similar to an ASP.NET application where the Server object provides a GetLastError method and there are global events for error handling. It's obviously a disconnected approach that doesn't really give any guarantee about the relationship to errors and operations. It's a best guess... This is easiest to implement and doesn't require changing the API. But it's obviously suboptimal. It's really a programatic hook into logging...
        Hide
        perry Perry Krug added a comment -

        Can we consider this closed given the release of 1.1?

        Show
        perry Perry Krug added a comment - Can we consider this closed given the release of 1.1?
        Hide
        mcstar Michael Schwab added a comment -

        Does this mean the entire set of Execute methods are going away? They used to provided the error details in the response which was very useful for debugging and taking corrective actions when errors occurred..

        Show
        mcstar Michael Schwab added a comment - Does this mean the entire set of Execute methods are going away? They used to provided the error details in the response which was very useful for debugging and taking corrective actions when errors occurred..
        Hide
        Ivan Ivan Vorobeychyk added a comment -

        If you go for "GetLastError" approach, the simplest way to keep error Id is to save it in ThreadStatic variable. User will call GetLastError immediately after failed operation, in the same thread where operation called. In this case there is no need to change API and all errors related to their operations.

        Show
        Ivan Ivan Vorobeychyk added a comment - If you go for "GetLastError" approach, the simplest way to keep error Id is to save it in ThreadStatic variable. User will call GetLastError immediately after failed operation, in the same thread where operation called. In this case there is no need to change API and all errors related to their operations.
        Hide
        john John Zablocki (Inactive) added a comment -

        Release with ICouchbaseResultsClient API

        Show
        john John Zablocki (Inactive) added a comment - Release with ICouchbaseResultsClient API

          People

          • Assignee:
            john John Zablocki (Inactive)
            Reporter:
            perry Perry Krug
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes