Official information may be found at the .NET Client Library page.
It is not possible to configure (in app|web.config) a single instance of a CouchbaseClient to work with multiple buckets. Though it is possible to programmatically reconstruct a client to work with multiple buckets, it is not recommended. The process of creating a client is expensive (relative to other Couchbase operations) and should ideally be done once per app domain.
It is possible however to set multiple config sections in app|web.config to allow for multiple client instances to be created, while still maintaining bucket affinity.
After defining the config sections, bucket specific clients are created by reading the appropriate config sections and passing the config section reference to the constructor of the CouchbaseClient. Again, constructing the client should not be done per operation, but rather per app domain.
The standard public API (i.e., Get, Store, etc.) exposed by the .NET Client Library is based largely on the .NET Memcached client library Enyim.Caching. These methods were created to support the use case of working with a distributed cache - not a persistent store. As a result, these methods return simple values and swallow exceptions.
For example, if an I/O exception occurred during the following call, then the value of getResult would be null.
Similarly, if the key already existed when the following snippet executes, the value of storeResult would simply be false.
In summary, for the standard API, retrieve operations will return null for cache misses, I/O exceptions and all other error conditions. Store operations will return false for key errors and I/O exceptions. No exceptions should bubble up to the caller when using the standard API.
In an effort to expose more about an operation's success or failure, additions to the API were introduced starting in client version 1.1. These new methods mirror the existing (while maintaining backwards compatibility), but are prefixed with "Execute." The return value of each of these methods is an instance of an IOperationResult implementation.
With the new API, a caller may use ExecuteGet to learn more about the state of an operation.
|Success||false when key is not found or exception is thrown|
|Exception||not null when a handled I/O exception is swallowed, null on operation failures|
|StatusCode||not null when server returns valid status code, null on I/O exceptions|
|Message||null when server returns valid results, not null on I/O exceptions or operation failures|
Similarly, Store operations return StoreOperationResult instances.
Generally speaking, testing the Success property is the starting point for checking for any failures. Success should never be false if an operation succeeded on the server (status code is 0). The various properties described above could then be used to test for swallowed exceptions or failed operations that didn't raise an exception.
Also, please note that there were missing code paths in the current version of the Enyim.Caching client that was released with the .NET 1.1 library. Specifically, operation failures that should report a StatusCode were falling through to a "Node not found condition." An upcoming 1.1.7 release will patch Enyim and resolve this issue - also reducing (or eliminating) the need for the InnerResult structure that currently is in place.