Feature Request: OptimisticLockingExecption about java-client-api

[rjrudin]

Thanks @ralfhergert , I'll do some research on this today and get back to you soon.

[rjrudin]

@ralfhergert Sorry for the delay, still have analyzing this on my to-do list!

[rjrudin]

@ralfhergert Turns out we have several tests for this feature already - all of which are doing what you're doing too! We somewhat surprisingly don't have any subclasses of FailedRequestException yet, but I see no issue with starting that pattern.

There are two similar codes:

• RESTAPI-CONTENTNOVERSION
• RESTAPI-CONTENTWRONGVERSION

Full list of REST API error codes is at https://docs.marklogic.com/11.0/guide/messages/RESTAPI-en .

I am wondering if it would be beneficial to use class names of e.g. ContentNoVersionException and ContentWrongVersionException that don't attempt to abstract over the error code. Would those be self-documenting enough to achieve your goal of both 1) not having to do a string check, and 2) making your code easier to understand?

[ralfhergert]

Hi @rjrudin, thanks for your response. Yes, the intended exceptions ContentNoVersionException and ContentWrongVersionException would work for us. They would achieve that we no longer have to implement the technical detail of "having to know the ML REST error strings". And they would allow us to catch the exceptions without further probing them for the underlying cause. - Looking forward to it. :)

[rjrudin]

Got it - we're doing a 6.2.1 release soon, I'm leaning towards sneaking this in even though it's technically a minor enhancement. The exception message won't change, just the class type, and it'll be a subclass of FailedRequestException.

[rjrudin]

Being addressed via #1590

[rjrudin]

Will be in 6.3.0, which will be released shortly.