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?

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.

  • 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 Nov 12 '13 at 12:23
  • You can vote on the answers you like ;) stackoverflow.com/about – Jan H Nov 12 '13 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 Nov 12 '13 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 Nov 27 '13 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;
    }
}
  • 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? – Dominic Cronin Jan 3 '14 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. – Peter Kjaer Jan 6 '14 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.

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.

  • 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 Nov 12 '13 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 Nov 12 '13 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 Nov 12 '13 at 14:18

Your Answer

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

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