Reduce HttpProblem dependency on Response.StatusType to the minimum #314
Conversation
lwitkowski
force-pushed
the
feat/response-status-decoupling
branch
from
1983c54 to
547e0dd
Compare
| return this.statusCode; | ||
| } | ||
|
|
||
| @Deprecated(forRemoval = true) |
There was a problem hiding this comment.
If you @Deprecate something it is best practice to document this in JavaDocs what part of new code replaces deprecated part (even if it is in same class).
I'd suggest also that we should mark this - in JavaDocs - for removal even for next minor version (3.2.0).
In case of community having struggle migrating to new version we can always revert it in 3.2.1.
On the other hand would like to get your point of view why we cannot keep it for developer convinence.
There was a problem hiding this comment.
Good points. I wanted to get rid of this class from `HttpProblem entirely, but it's still heavily used in the builder by mappers. On the other hand, it will return null for 422 and other non-standard codes.
I'll remove this deprecation now, it's not that critical.
There was a problem hiding this comment.
Well, with this note on null statuses I'm actually in favor of removing it in future.
But agree on not being critical for release.
This will allow some certain future features to be much easier to implement, it also reduces non-null checks as we're relying on
intstatus code, not nullableResponse.StatusType