Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom error messages #103

Open
flintforge opened this issue Feb 5, 2022 · 1 comment
Open

Custom error messages #103

flintforge opened this issue Feb 5, 2022 · 1 comment

Comments

@flintforge
Copy link

flintforge commented Feb 5, 2022

Errors raised in a resolver — let's take

ErrValueError:  "Field '$1' cannot be resolved: \"$2\"" % [msg[0], msg[1]]

get they type after a RespResult holding a message string and the place where they're occur.
Comparing the situation to other GraphQL implementations, I'm wondering if there's a way to provide custom error messages ?
Perhaps raising an other exception when an unspecified error kind is met,
and adding a custom one with no formatting along the lines ?

"ASSERT: UNSPECIFIED ERR KIND: " & $err

Also, is it possible to stack them in a sequence before returning ?
I tried with ctx.errors.add but this is a user context, not the calling one (if that makes sense, but I'm still building the mental picture of the mechanisms). If not I would gladly PR on that.

@jangko
Copy link
Contributor

jangko commented Feb 8, 2022

currently the resolver is using this return type:

RespResult* = Result[Node, string]

if you need custom error message, a possible alternative is using object variant to replace the string.

type
  RespErrorType* = enum
      SimpleMsg      # formatting handled by executor
      CustomMsg    # formatting done by user
      ListMsg           # return one or more error messages
      etc.

  RespError = object
     case typ*: RespErrorType
     of SimpleMsg:  msg*: string
     of CustomMsg: customMsg*: string
     of ListMsg: listMsg*: seq[string or errorobject]
     etc.

  RespResult* = Result[Node, RespError]

then you need to overload err to provide backward compatible helper proc.
the rest is quite straight forward modification in executeField of executor.nim.

But if you have other solution, we can discuss it further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants