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?
