rest icon indicating copy to clipboard operation
rest copied to clipboard

NotImplementedException to go with Response.Status.NOT_IMPLEMENTED & friends

Open derekm opened this issue 6 years ago • 15 comments

Provide equivalent exception types for the new v2.0 Response.Status fields.

derekm avatar Jun 17 '19 04:06 derekm

@derekm Feel free to provide a PR. :-)

mkarg avatar Jun 18 '19 05:06 mkarg

Just so if anyone is thinking about work on this on, i'll send a PR about it shortly.

jeyvison avatar Jun 29 '19 19:06 jeyvison

There are open comments in PR #774 that have to be addressed before we can close this issue.

mkarg avatar Nov 07 '20 15:11 mkarg

Does this issue still need to be targeted for 3.1?

spericas avatar Aug 25 '21 15:08 spericas

@spericas -- I think not having exceptions for all statuses is an oversight. It is nice to cause specific status codes in responses simply by raising the corresponding exception. Having all users constantly re-invent the wheel by providing their own exceptions in such cases strikes me as somewhat malicious.

derekm avatar Sep 10 '21 15:09 derekm

@derekm We need someone to submit a PR :)

spericas avatar Sep 10 '21 15:09 spericas

@spericas -- It looks like @jeyvison's PR was rejected. To me it is all or nothing, and Jeyvison's PR looks like it went with "all," but some maintainers want user-programmers to constantly reinvent these wheels. Now it seems like a matter of lobbying for the rejected PR.

derekm avatar Sep 10 '21 15:09 derekm

@derekm Not everyone agrees on the all or nothing approach; if a middle ground will not cut it, we might just as well move on ...

spericas avatar Sep 10 '21 15:09 spericas

@spericas -- How do we know which ones are worth implementing or which exceptions won't be rejected if implemented? I was asking for exceptions for "NOT_IMPLEMENTED & friends." Just implement them one-by-one and see which of n PRs aren't rejected?

derekm avatar Sep 10 '21 15:09 derekm

@derekm No, you submit the PR with the proposal and update it based on the feedback received and until you get the necessary approvals. If I recall correctly, last time the comments were never addressed. It's really not that complicated, and the way all PR's get accepted.

spericas avatar Sep 10 '21 16:09 spericas

@spericas -- I think not having exceptions for all statuses is an oversight. It is nice to cause specific status codes in responses simply by raising the corresponding exception. Having all users constantly re-invent the wheel by providing their own exceptions in such cases strikes me as somewhat malicious.

No this is not an oversight. JAX-RS is just a foundational API that provides the boilerplate for others to build third-party libraries. It is not a REST framework, it just contains the really essential return codes. Such a common library easily could provide lots of status codes and become something like Apache Commons.

mkarg avatar Sep 11 '21 07:09 mkarg

@spericas -- Yes, I'm aware how PRs work. 😄 Which is why I'm asking question so I don't just shoot in the dark trying to bring this home, as I think it is very valuable (and very late).

The only unaddressed comment I can find across a mess of PRs is from @chkal, which paraphrases to "maybe don't implement RequestHeaderFieldsTooLargeException or RequestedRangeNotSatisfiableException". I can imagine many instances where an application might forward requests to other systems using header or range data, in which case these exceptions could be handy.

Only these two exceptions are at issue and need to be removed? Why even pare it down on just 2 exceptions?

@mkarg -- Interesting... I use JAX-RS directly without any additional libraries. I find it quite suitable to use standalone, minus some minor wheels I have to constantly re-invent or provide to myself via internal dependencies -- hence this issue. Probably I should get my private utility libraries on maven central or something (e.g., https://github.com/derekm/jaxrs-ext).

derekm avatar Sep 13 '21 14:09 derekm

Hey Folks :) I'm sure i addressed everything that was supposed to be addressed at the time. For what i understand , it was closed bacause we didn't get a consensus on what to keep. If we know now it now i'm more than happy in changing my PR and resend it

jeyvison avatar Sep 14 '21 17:09 jeyvison

@jeyvison Seems like there is some interest in your PR. If you re-submit, I'll take a closer look and provide a review. Let's give it another shot. Thanks.

spericas avatar Sep 15 '21 13:09 spericas

@mkarg -- Interesting... I use JAX-RS directly without any additional libraries. I find it quite suitable to use standalone, minus some minor wheels I have to constantly re-invent or provide to myself via internal dependencies -- hence this issue. Probably I should get my private utility libraries on maven central or something (e.g., https://github.com/derekm/jaxrs-ext).

Interesting! In fact, in my daily use of JAX-RS, I am using approx. 10 external feature libraries for things like caching, compression, benchmarking, and other stuff.

mkarg avatar Sep 15 '21 20:09 mkarg