{"action":"created","issue":{"url":"https://api.github.com/repos/yavijava/yavijava/issues/112","labels_url":"https://api.github.com/repos/yavijava/yavijava/issues/112/labels{/name}","comments_url":"https://api.github.com/repos/yavijava/yavijava/issues/112/comments","events_url":"https://api.github.com/repos/yavijava/yavijava/issues/112/events","html_url":"https://github.com/yavijava/yavijava/issues/112","id":94196565,"number":112,"title":"Add Relevant Messages to Faults","user":{"login":"aaron-brown","id":1149585,"avatar_url":"https://avatars.githubusercontent.com/u/1149585?v=3","gravatar_id":"","url":"https://api.github.com/users/aaron-brown","html_url":"https://github.com/aaron-brown","followers_url":"https://api.github.com/users/aaron-brown/followers","following_url":"https://api.github.com/users/aaron-brown/following{/other_user}","gists_url":"https://api.github.com/users/aaron-brown/gists{/gist_id}","starred_url":"https://api.github.com/users/aaron-brown/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/aaron-brown/subscriptions","organizations_url":"https://api.github.com/users/aaron-brown/orgs","repos_url":"https://api.github.com/users/aaron-brown/repos","events_url":"https://api.github.com/users/aaron-brown/events{/privacy}","received_events_url":"https://api.github.com/users/aaron-brown/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-07-10T02:17:08Z","updated_at":"2015-07-10T04:28:22Z","closed_at":null,"body":"@michaelrice, it's been a huge bugbear of mine that VIJAVA always produced this kind of messaging when logging any of the Faults that occurred:\r\n\r\n```text\r\ncom.vmware.vim25.NoPermission: null\r\n```\r\n\r\nThis is because (to my knowledge) _all_ of the faults don't actually set a message ([**NoPermission**](https://github.com/yavijava/yavijava/blob/6.0.01rc1/src/main/java/com/vmware/vim25/NoPermission.java) as an example; ```message``` (neither in **NoPermission** itself, nor in any of its chain of inheritance) implement a standard message. Or, there's something about the library that I don't know about that would give a kind of standard message.\r\n\r\nDo you think it would be possible (and a reasonable investment) to add relevant messages as a part of these Faults (**Exceptions**), so that application users aren't forced to explicitly identify and come up with a message for each individual Fault _just_ to supply any of the relevant fields that the fault may contain, in a contextual message for application-feedback?\r\n\r\nA couple advantages I see to doing this:\r\n\r\n1. The library will provide a standard message that can be forwarded / passed along more intuitively when passing these Faults into another **Exception** as a ```cause```.\r\n\r\n2. This reduces the number of ```try / catch``` blocks necessary at the application level solely for the purposes of providing contextual information in **Exception**-handling (for example, simply catching ```Exception``` for any Faults or other **Exceptions** will no longer be a detriment when it comes to providing feedback about that Fault). ```catch```ing any specific Fault would then be for more practical and relevant reasons, for example to alter a process flow based on a particular Fault.\r\n\r\n3. This can provide a better foundation for these Faults to be extended upon, if desired, in a more intuitive and complete way (most Java-developers would _want_ to include a message, or have one included, I would imagine).\r\n\r\n4. It will reduce the level of redundancy and repeated code throughout applications, and the potential for handling these Faults poorly _solely_ for the purposes of providing context around them to end-users and/or troubleshooters.\r\n\r\nLooking at the code, I'm saying this with not much context as to how these Faults are generated, and it may have been that including a custom ```message``` for each Fault would have been something that fell outside the realm of code that could be easily and \"factory\" generated, considering the messages would have to be (likely) hand-tailored and maintained. So, I'm saying this as solely an idea-pitch without much insight as to how it might be implemented / maintained.\r\n\r\nThoughts? "},"comment":{"url":"https://api.github.com/repos/yavijava/yavijava/issues/comments/120222049","html_url":"https://github.com/yavijava/yavijava/issues/112#issuecomment-120222049","issue_url":"https://api.github.com/repos/yavijava/yavijava/issues/112","id":120222049,"user":{"login":"michaelrice","id":441148,"avatar_url":"https://avatars.githubusercontent.com/u/441148?v=3","gravatar_id":"","url":"https://api.github.com/users/michaelrice","html_url":"https://github.com/michaelrice","followers_url":"https://api.github.com/users/michaelrice/followers","following_url":"https://api.github.com/users/michaelrice/following{/other_user}","gists_url":"https://api.github.com/users/michaelrice/gists{/gist_id}","starred_url":"https://api.github.com/users/michaelrice/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/michaelrice/subscriptions","organizations_url":"https://api.github.com/users/michaelrice/orgs","repos_url":"https://api.github.com/users/michaelrice/repos","events_url":"https://api.github.com/users/michaelrice/events{/privacy}","received_events_url":"https://api.github.com/users/michaelrice/received_events","type":"User","site_admin":false},"created_at":"2015-07-10T04:28:22Z","updated_at":"2015-07-10T04:28:22Z","body":"Wait I appear to be wrong here. There is even more parsing  (Thanks to reflection) of the SoapFaultException later and only the `detail` from the SFE is converted (via reflection) into the vmware fault. So the `faultString` which seems to contain a message from the server that seems fitting to go in `faultMessage` or `detailMessage` looks like its being eaten and never passed along because its not in the NotAuthenticatedFault soap message thus reflection never does its thing to get it set.\r\n\r\nHere is a payload coming from the server for example:\r\n ```xml\r\n<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<soapenv:Envelope xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:soapenc=\"http://schemas.xmlsoap.org/soap/encoding/\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\r\n<soapenv:Body>\r\n    <soapenv:Fault>\r\n        <faultcode>ServerFaultCode</faultcode>\r\n        <faultstring>The session is not authenticated.</faultstring>\r\n        <detail>\r\n            <NotAuthenticatedFault xmlns=\"urn:vim25\" xsi:type=\"NotAuthenticated\">\r\n                <object type=\"Folder\">group-d1</object>\r\n                <privilegeId>System.View</privilegeId>\r\n            </NotAuthenticatedFault>\r\n        </detail>\r\n    </soapenv:Fault>\r\n</soapenv:Body>\r\n</soapenv:Envelope>\r\n```\r\n\r\nWhile this isnt ideal it does completely reflect the behavior of the API and directly implements the behavior described by the WSDL. I want to look at rbvmomi and pyVmomi to see how its handled in those. Now Im curious."}}