Get error description from remoteAdministrationCall

Lex Clay shared this idea 57 days ago
Idea Logged

Hello again Fishies,

Another simple thing that somehow has me stumped...when processing a webservice call & forcing an ERROR statusCode, what's the call to get the error description?

I know the code is obtained from getErrorCode(), what I want is the bit you see in the Tomcat output (the bit in bold below)

WebserviceException caught: 38(PASSWORD_REQUIREMENTS_NOT_MET)

Comments (1)

photo
1

Hi Lex,


You might want to try getReason(), getErrorReason() or getReasonCode() to see if they work, but I can't find specific mention to them in our documentation.

Let me know how that goes.

Kind regards,

Chris

photo
1

Hi Chris,

Unfortunately, all of those return The method xxx is undefined for the type AdministrationServiceResponse

photo
1

Hi Lex,

Thanks for coming back to me so quickly. I'll have to put this one to our dev team to see if there's an available undocumented call.

Kind regards,

Chris

photo
1

Hi Lex,

One option would be to try getStatusCode(), but I believe that might refer to something else. Let me know if that gives a result.

Kind regards,

Chris

photo
1

Hi Chris,

Sorry, I only just saw the email notification for this. I don't need to test that...getStatusCode returns SUCCESS or ERROR...(not teaching you to suck eggs but for clarity of anyone else reading this in the future)


if("SUCCESS".equals(rs.getStatusCode())){
    // The call worked, do some funky stuff
} else {
   // Oops there was an error.  Code is rs.getErrorCode() description is..... ;)
}

photo
1

Hi Lex,

Okay thanks, hopefully the dev team have this coded, but there's a possibility it might not exist yet for this object class. Will let you know.

Kind regards,Chris

photo
1

Hmmm... Seeing as the description is output to the tomcat console, it must exist somewhere. If there isn't an explicit method, knowing where the map from code to description is might be enough to write a custom call to scrape the info from there.

photo
1

Hi Lex,

Unfortunately there isn't currently a specific parameter for the object that contains the reason. There is 'Messages' which can give some information, but it doesn't always return useful information. If you have a look inside the webservices response, you can see from the screenshot below that Messages returns a more specific reason as to why it has failed, in this case the given password length doesn't meet the minimum requirements. There should be a getMessages() method.

I hope that helps!

/7885e7978eb9323fd2ca9704fbe7480e

Kind regards,

Chris

photo
1

Hi Lex,

I have also found an example of getMessages() being used in a code example below, which relates to the ENABLEADMINMODE webservice:

/d24e2d46f1d132c35a998271ea5175f8

Kind regards,

Chris

photo
1

Thanks Chris...had an initial play with it, passing java arrays back to javascript...bleugh...I suddenly understand why Yellowfin just displays "Oh no an error has occurred" :)


Do you know if it's always the 3rd element in the java array that contains the actual error message? For example, rather than passing back the entire java array and having to faff around with that, can I just use rs.getMessages()[2] ?


I know you guys are focused on the new REST API & I haven't looked into it at all yet really, so adding this level of error handling there if it doesn't already exist would be good.

Cheers.

photo
1

Hi Lex,

Yes, that's an almighty headache! And part of the reason why we have error codes and a lookup table on the wiki :)

After a bit of experimentation, I'm pretty sure that it's always the third element that has the error message.

I can create an idea post for some more error handling functionality, but it would probably fall under the 'nice to have' priority and it could be a while before it's implemented.

Kind regards,

Chris

photo
1

Ha..yeah the wiki doesn't really help with displaying error messages via a UI though.

Not sure I agree with the nice to have to be honest, it's definitely more commonplace to display a message rather than just an error code but there's little to be gained from debating that point.

If you could go ahead an create the idea post, eventually it will save those of us using YF as a development platform a hell of a lot of unnecessary headache.

Seriously, thank you for spending the time you have getting to this point though, my only other option was to create my own lookup table which would have been a horrible increase in execution time.

Once you've logged the idea thing, feel free to close this off chap.

photo
1

Okay, that's done, I'll mark this as enhancement logged and you can use this post to track progress.

photo