I have developed a soap based web service. It returns java objects which contains data fields as well as error code and error message fields in case any error occurs or any exception is carched.
I have heard of soap fault messages that should be used for errors and exceptions.
My question is should i stick with current approach or should i use the soap fault messages?
Use SOAP Faults. That's why they were invented.
Using faults, your wsdl2java or equivalent tool will create a Java exception class for each fault type. When the fault occurs, the callers of the service can catch it using try/catch blocks. This makes it much easier to use the service, as it will not be necessary to check for error codes on every call.
It also means that code can't just forget to check for error codes.
Related
I'm using loopback 3 which based on expressJS. I noticed that sometimes the nodeJS app exit when runtime error occurs but sometimes just showing the error but not exit and the app continue functioning.
Can someone explain in what types of runtime errors the entire app terminates and what type not?
I suggest to check your code carefully, it looks like you missed "await" for a promise somewhere. Generally, all errors should be caught by the error handler (if we are token about requests processing)
I'm using AmazonSQSClient to interact with the SQS service and using the default client configuration which means it already is using the DEFAULT_RETRY_POLICY.
Let's say I make a call in my Java code to the "sendMessage" method.
As per the doc, the method can throw 2 types of Exceptions: InvalidMessageContentsException & UnsupportedOperationException.
Now let's say that the SQS service was unavailable due to whatever reason, and even after retries the SQSClient could not perform the sendMessage operation. I'm trying to understand how would I get to know that in my Java code. I can catch the aforementioned exceptions but I don't think these exceptions would have the info I need. They seem more related to an invalid message or an unsupported operation.
Am I missing something? Thoughts?
This looks like the relevant Java SDK code. This section leads me to believe you'll receive a SdkClientException with the causal exception inside of it.
When using Spring-WS as a SOAP client, I have a hard time converting incoming faults to their specific Java Exceptions.
For example, if the web service operation I am calling can return a ClientNotFoundFault and let's say, an InvalidAmountFault, can I make Spring-WS throw either a ClientNotFoundException or an InvalidAmountException?
Can Spring-WS throw something different than SoapFaultClientException?
I can do this the other way around when writting the web service myself. There, using the SoapFaultMappingExceptionResolver, I can easily convert Exceptions into their equivalent fault. I just couldn't find anything about doing it when writting the client...
I am using Spring-WS 2.1.0.RELEASE with JDK 1.7.6
Thanks and let me know if I am not clear enough or if you need some code example.
There is no equivalent resolver on the client side. The resolver interface is there all ready for someone to write a similar mapper. Should be very straight forward to hold a map of fault codes vs exception classes.
See org.springframework.ws.client.core.FaultMessageResolver
This is implemented by SoapFaultMessageResolver at the moment which simply wraps the fault message in the SoapFaultClientException that you are seeing.
I have a c++ NTservice which is being accessed by SAP modules through rfc calls. Now this service is getting stopped with a message that "this application has requested the runtime to terminate it an unusual way" and then showing some IE script error that points to url "res://C:\WINDOWS\System32\mmcndmgr.dll/views.htm" -- I am getting this error very rarely and unexpectedly.
I have no clue why this error is coming, please anyone can guide me about the details and how to correct it if possible
(Windows xp, service is created in MSVC 2005)
Thanks,
Anil
That error message (at least usually) means you had an uncaught exception. You could start by adding a try/catch(std::exception const &e)/catch(...) to your ServiceMain, in an attempt at catching the exception and if it is a derivative of std::exception, printing out its what() to see what it has to say for itself...
That's the very unhelpful message that displays when your executable has crashed. Almost anything could be wrong.
Run your executable through a debugger and wait for the problem to occur. You can then try to find out more information about it.
In particular I'd check the service's documentation and make sure that your SAP modules are using the RFC calls correctly.
I'm designing a WCF service that will return a response code (such as 0 for success, or another number for errors). Also, all methods of the web service will perform several common validations (such as authenticating an apiKey).
I am wondering if there is a best practice approach or organizing and retrieving these response codes and messages.
Thanks for any suggestions.
Ideally, don't use response codes. Return something usable on success (or void) and throw an exception on failure.
People deal with exceptions. We often forget to look at returned codes, especially when 99% of the time it's success, and we don't care about any response. So we don't capture. Then we don't bother checking for failure. Then we spend 2 days tracking down a bug that we can't find because no exception was thrown and we have no idea where the 600,000 line application failed that used your webservice... we don't even know it was a call to your webservice that failed. Just that some data is wrong for some unknown reason.
There's a topic on SO about this: Which and Why do you prefer Exceptions or Return Codes
Don't use return codes directly. Return codes usually mean success, set of expected fails and unexpected fail. Web services replace this mechanism with expected faults and unexpected faults. Check FaultContract and FaultException<T> for implementation details for expected faults. Unexpected fault is any other exception. That is the best practice.