Is it possible to get more precise errors from the API?

Hello SDL Developers,

let me give you some background on my request:

We are very often faced with problems that users have, when they work with our connector to SDL Studio.

Our connector shows to the user any exceptions which we get, when running automated Tasks on the project. But very often, they are not precise enough and so someone has to find out, what the user made wrong or what is the problem in the configuration they've made.

Let me give an example here:

We are running the automated task: AutomaticTaskTemplateIds.UpdateMainTranslationMemories on the project. The message, that's comming back is: 'No translation memories found to update for language pair XXX -> YYY'. So far not bad, but there are now variuos things that we have to check to tell the user what he has made wrong. In the example above the user had not ticked the Update Checkbox for the TM. So SDL basically acted correct, but it should give this information back. This would save us time and your support as well, I would say.

So is it possible for you guys to extend the ExecutionMessage with additional info, when you have it availlable?

 

Kind regards,

-Stephan Tandel-

Parents Reply
  • Hey Romulus,

    thanks for your answer. We're using the first option you mention. Does the second option return different/more precise information on the cause of a problem?

    If not, then it doesn't help. We could of cause, like Jesse wrote, extend the error with our custom error message, but that's wrong in my understanding of an API Design. In the example I mentioned, how can our software know, that an action is not possible because of a specific (incorrect) configuration in SDL Studio? And as Studio changes of cause, we would have to addapt our custom messages as well.
    So to me, the API should point to this problem more exactly.

    But in general it is more or less impossible to prepare a list of API calls, where more precise error messages are needed. Perhaps you should take it as a general quality requirement to the API developments. With this written, i know that it's hard to measure if the result message is ok or not. But the more information the API can give back, the better.

    All the best,
    -Stephan Tandel-
Children