[
https://issues.apache.org/jira/browse/TINKERPOP3-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947401#comment-14947401
]
David M. Brown edited comment on TINKERPOP3-869 at 10/7/15 7:13 PM:
--------------------------------------------------------------------
A few thoughts and questions:
I've never heard of anything like this before, have you seen a similar feature
with other servers? I can see why you would want to test all of the possible
error codes that the server produces and I must admit that I haven't done this
with my clients; however, it seems to me that you should be able to write
client side tests that result in the server raising each one of the errors
listed in the developer documentation without adding a special op to do so. Is
it possible to reproduce all the errors in client tests? If not, maybe a bit of
documentation on how to do so would be worth more to us as driver developers
than a separate feature.
was (Author: davebshow):
A few thoughts and questions:
I've never heard of anything like this before, have you seen a similar feature
with other servers? I can see why you would want to test all of the possible
error codes that the server produces and I must admit that I haven't done this
with my clients; however, it seems to me that you should be able to write
client side tests that results in the server raising each one of the errors
listed in the developer documentation without adding a special op to do so. Is
it possible to reproduce all the errors in client tests? If not, maybe a bit of
documentation on how to do so would be worth more to us as driver developers
than a separate feature.
> Adding a UtilityOpProcessor for gremlin-server
> ----------------------------------------------
>
> Key: TINKERPOP3-869
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-869
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: server
> Affects Versions: 3.0.1-incubating
> Reporter: Dylan Millikin
> Assignee: stephen mallette
> Priority: Minor
>
> This is a proposal for the addition of a UtilityOpProcessor.
> The initial idea behind this OpProcessor is to allow driver developers to
> have easier means of testing their error management. But it could extend
> beyond that.
> The initial implementation would probably possess an op of {{throw}} that
> would be fed the following {{args}}:
> {code}
> {
> "exception": {"message":"This is an error.", "code":500}
> }
> {code}
> Or we could also imagine :
> {code}
> {
> "exception": {"class":"OpProcessorException", "message":"This is an
> error.", "code":500}
> }
> {code}
> Though I'm not sure how useful this would be. And it would probably also have
> security implications so it's really just here for posterity.
> ---
> After receiving these the server would return the described error as per the
> driver building documentation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
