11

I am trying to distinguish different Exceptions being thrown in the core service. The core service throws only one Type of Exception: CoreServiceFault. Now I want to start reading the ErrorCodes to distinquish them.

Now the thing I am searching for is a list of various Errorcodes/Messages etc so I can distinquish the errors.

Anyone got a list or a suggestion?

5 Answers 5

12

The CoreServiceFault error codes are not documented in the API documentation and I think the list of error codes is not in the Tridion.ContentManager.CoreService.Client.dll either.

Maybe this could be explained because it is up to the Core Service to throw the fault, the client cannot have a complete list of all fault codes.

I think you should check e.Detail.ErrorCode and e.Detail.Messages and raise them as an excption, you cannot write too much logic based on the ErrorCode anyway since it is not a documented list.

4
  • Thanks, this is the answer I have been looking for. Just found it myself as we speak. I hope that we can find a list somewhere, anytime. It would make sense because it would help on making sense on the exceptions. Although the message's give a pretty good Idea of what is going on.
    – Noldy
    Commented Nov 12, 2013 at 12:23
  • You can vote on the answers you like ;) stackoverflow.com/about
    – Jan H
    Commented Nov 12, 2013 at 12:38
  • 1
    And welcome to the site! You could help the Tridion community by taking the next steps. Post an idea on ideas.sdltridion.com to add ErrorCodes to the API (and post the link on this site so we can vote for your idea). Make a question on tridion.stackexchange to collect known error codes. Blog about, or create a Gist, with the ErrorCodes you found.
    – Jan H
    Commented Nov 12, 2013 at 12:42
  • I added the suggestion on ideas.tridion.com and it got rejected because I used an external link to this post. I haven't found the time to submit a new idea.
    – Noldy
    Commented Nov 27, 2013 at 9:32
12

You can access the error code by catching the exception as FaultException<CoreServiceFault> and then accessing the Detail property. For example:

try
{
    client.Delete(itemId);
}
catch (FaultException<CoreServiceFault> ex)
{
    switch (ex.Detail.ErrorCode)
    {
        case "PermissionDenied":
            // Do something specific to the user not having access
            break;
        case "ItemDoesNotExist":
            // Maybe you should have checked client.IsExistingObject before trying to delete :)
            break;
    }
}
2
  • If an API throws exceptions, those exceptions are part of the API. If the correct way of processing the exceptions is to use the error code, then that's part of the interface, right? Or is there a reliable method of identifying exceptions that we should use instead? Commented Jan 3, 2014 at 12:28
  • You are right, of course. I meant to say that the specific error codes used by a given method might change over time. I've removed the note since it wasn't really adding anything but confusion. Commented Jan 6, 2014 at 9:27
6

I don't know, how you want distinguish them exactly (assuming, that in some place you can get TcmErrorcodes of some specific types...for example on saving schema you can get InvalidXSD = 0x0328,when XSD of the schema is null). To find list - look to TcmErrorCode enum in the Tridion.ContentManager.Common assembly.

2
5

In addition, one more observation that I have experienced (Not with Core Service but with the TOM.NET API) and wish to share - We had received same error codes for two absolutely different errors while I was trying to do a POC for some business requirement and wanted to raise some user friendly errors by identifying the Error Codes and to my surprise I got two different errors but same error code, so be cautious if you are trying to do something like that.

4

Btw, you can still go with Exception names...I have similar code example, as Peter:

 try
        {
            return _client.Read(
                itemId,
                new ReadOptions()
                );
        }
        catch (FaultException<CoreServiceFault> e)
        {
            if (e.Detail.ExceptionName == typeof(ItemDoesNotExistException).Name)
            {
                return null;
            }
            throw;
        }

So, you can still go with exception names, but not errorcodes.

3
  • 1
    I like this way for solving my problem. Allthough I still would have like a list of possible exceptions that can manifest in the FaultException.
    – Noldy
    Commented Nov 12, 2013 at 13:31
  • I don't know which version of Tridion Core Service you are using. For 2011 e.Detail.ExceptionName is a string.
    – Noldy
    Commented Nov 12, 2013 at 14:08
  • I use typeof(Exception).Name - it is string as well. My suggestion - you must look to your problem context...somewhere it will be enough to have only ExceptionName, somewhere you need to use errorCode(usually it shows the exception reason deeper). For example on Schema/Content validation you can get InvalidXmlException with different errorCodes.
    – Syav4eg
    Commented Nov 12, 2013 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.