0

We have an off shore group that is responsible for a SOAP service.

The service has a method that returns a key as a string, when everything goes correctly. When it doesn't the key is an error string. A short pseudo-code demonstration:

 var key = soapService.GetKey(username, password, moreFields);
 var assignments = soapService.GetAssignment(key);

key in this case should be what appears to be a UUID. But if something is wrong, it instead is an error string:

ERROR - Could not get user
ERROR - Timeout
ERROR - Service tried really hard to get a result, but it didn't because some of the fields indicicated a use case that wasn't handled correctly.

I want to handle any errors before making additional requests (RESTful API calls the SOAP service)

My initial pattern looks something like this:

Dictionary<string, string> KnownErrors = new Dictionary<string, string>()
{
    {"ERROR - Timeout", "TimeOut"},
    {"ERROR - Could not get user", "User Not Found"}
};
if (knownErrors.ContainsKey(soapResult))
{
   // handle appropiatly, and notify caller with custom JSON and not a 200 Status Code
}

The obvious problem, error messages could change, and I don't want to update code / tables with known error codes if it is avoidable.

I could make it fall back with something like:

if (knownErrors.ContainsKey(soapResult))
{
   // handle as before
}
if (soapResult.Contains("ERROR")
{
   // handle as well, message defaults to:
   var errorMessage = soapResult.Split('-')[1].Trim();
}

My concern then becomes, if I fall back to splitting the string, I am probably over thinking the problem by trying to do it with the dictionary the first time.

Are there standard, and more reliable patterns for magic string errors that look like valid response strings?

4
  • The SOAP response should clearly indicate success or failure instead of leaving you to search for magic strings.
    – Dan Wilson
    Aug 29, 2019 at 14:36
  • @DanWilson absolutely agreed, but for now let's consider that an unsolvable problem.
    – AthomSfere
    Aug 29, 2019 at 14:41
  • 2
    OK. Can't you simply check whether the string is a UUID and consider anything else an error?
    – Dan Wilson
    Aug 29, 2019 at 14:44
  • @DanWilson I'd have to research, but that might be a good path! Or at least is it a BAN / Hex. I say it appears to be a UUID because it looks possibly shorter... It could be a weird internal string hashed oddly too...
    – AthomSfere
    Aug 29, 2019 at 14:52

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy