Forum Discussion

Lerna_Ekmekciog's avatar
Lerna_Ekmekciog
Icon for Nimbostratus rankNimbostratus
Oct 26, 2005

iControl Exceptions

Hi,

 

 

When iControl methods throw exceptions such as Common.OperationFailed or Common.AccessDenied, etc. I can only catch them as Exception and not as CommonOperationFailed. This is because CommonOperationFailed and all other iControl exceptions do not exist as part of the package. Is it true that you do not expose the specific exceptions within the iControl package or are they included in the package ? Do you think there was a problem converting these from wsdl2java?

 

 

Lerna

3 Replies

  • Lerna,

     

     

    Back when we first implemented iControl (2001) SOAPFaults were only allowed to consist of a string so we chose to include the exception contents within that string. Not the most ideal implementation but that was all that we had.

     

     

    Since then, the SOAP specs have been enhanced to support extendable Faults but not all client environtments support it so we opted to keep our original implementation in place.

     

     

    So to answer your questions: No, we don't expose them as separate distinct exceptions but require the client to parse the response. And, No, this isn't a problem with wsdl2java.

     

     

    -Joe
  •  

    Hi Joe,

     

    I can see its long time since you sent this response. I recently came across the same problem and want to know whether the policy of not exposing these exceptions remain same as of now? Do we still need to manually parse the response?

     

     

    Thanks,

     

    -Kalpesh
  • Unfortunately yes. For us to change the format of the message contract, would break existing applications. What scenario are you looking at where you are trying to parse an exception? Also, what language are you using? I can write up a language specific fault parser for you if that helps.

     

     

    -Joe