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...
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...
John Zablocki
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...
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..
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..
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.
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.
Improvement
Closed
Major
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...