This error is thrown in an exception when I call a bucket->query. It doesn’t fail if the query is simple like "SELECT * from ‘default’ ". But if I add something like " WHERE collection = ‘somevalue’ " it throws the error. And I guess there’s no way to get the response code or status from the underlying HTTP request. You can only get the status if the exception is not thrown. Is there in fact a sneaky workaround that is not mentioned in the docs? Is there a way to get the actual “status code” that it proposes to “inspect” ? The docs for the PHP SDK are very raw, by the way. Almost no explanations and code samples.
2.2.2 release will be reporting details as a warning using php_error_docref, meanwhile you would either test your query in Admin Console, or look into tcp dump.
Are there compelling reasons to not just include the information in the exception? In this example, this means digging in the logs for bringing the caught exception and the underlying cause together. The effort is even higher, if the whole tooling around errors is built around the “standard PHP errors”. That’s why from my perspective the whole idea of having a separate PHP SDK error handling including its own log levels etc. is suboptimal. Our developers have no direct access to the error log. With the current solution our custom PHP error handler is bypassed an the developer doesn’t even see that he triggered an Couchbase warning/error in the log. Why not just do the equivalent of a trigger_error() in these cases?
Thank you for the feedback, I plan to improve error handling. Currently it is not always easy to capture error information and put it into the exception, but it is possible. Thanks for the trigger_error idea, I will consider that too.