-
Notifications
You must be signed in to change notification settings - Fork 1.2k
A default implementation of DataFetcherExceptionHandler.onException #2614
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
Changes from all commits
df4cc56
3f3e1bc
5f61f53
f3dd281
43c2b0c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -27,7 +27,9 @@ public interface DataFetcherExceptionHandler { | |
| * version | ||
| */ | ||
| @Deprecated | ||
| DataFetcherExceptionHandlerResult onException(DataFetcherExceptionHandlerParameters handlerParameters); | ||
| default DataFetcherExceptionHandlerResult onException(DataFetcherExceptionHandlerParameters handlerParameters) { | ||
| return SimpleDataFetcherExceptionHandler.defaultImpl.onException(handlerParameters); | ||
| } | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we undefault the other method in this same PR (and hence 18.0 version)? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's better to keep default implementation on the new method or otherwise existing implementations would not work until they implement it. |
||
|
|
||
| /** | ||
| * When an exception occurs during a call to a {@link DataFetcher} then this handler | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't this be just
IllegalStateException? Either a class implements the new method, in which case this is not used, or it overrides this one. Either way this implementation should never be called.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is more when do we decide to break older implementers. if the new CF based
handleExceptiondoes not call the olderonExceptionthen every one out there that previous implementedonExceptionwill break. Because our code will call their method.Do really it's a case of deciding WHEN we break backwards compat in behavior. That is all those old
onExceptionmethods will stop working even if its deprecrated.So ... should that be now? This new CF based method was introduced in 17.x - 18.x is next. Is one version enough? I kinda think it should be two versions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to clarify, the new handleException should continue to call onException as it does now. I'm not suggesting otherwise. I'm not sure how long the deprecation period should continue, but I see no reason not to give it ample time. When that's over, drop onException and remove the the default implementation from handleException.