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.
Related
This is a general, architecture question, not a request for code examples or particular code solutions.
In a multi-layered applications we have 2 major options of handlings service layer validations:
Service layer throws exception which Presentation layer should catch and handle.
PRO for this approach is lightweight service layer signature but on the other hand there is a potential overhead of exceptions being thrown all around the place and since exceptions themselves are not the cheapest options one might want to reconsider this option.
Introduce ServiceResponse wrapper type
The type might be something like (pseudo code):
class ServiceResponse{
boolean IsOk;
array ErrorMessages;
object OkResponse;
}
This is also in line with REST Services (although question is not about them) where Http response message actually acts as a ServiceWrapper with its StatusCode and Content.
What approach do you prefer in your service layers and why?
If Iam understanding your question correctly, your service layer is a library of some sort that you inject or depend upon, in your UI layer. It's better to throw exceptions at this level. If you ever decide to **Physically separate ** the services layer and expose it via an API layer (REST). You can always catch those exceptions at API Layer and return http response with correct http code and exception message. So yeah stick to exceptions to start with.
I am using Lambda function for populating Dynamo DB. I need to log the event details in cloudwatch to know the exception if some occurs. I am able to configure cloudwatch logs for the lambda function but it is showing other debug statements that is leading to unwanted logging. Is there any way to configure that.Any help will be appreciated.
OK, I think I misunderstood your question. Apparently (from your comment) you're using log4j. The way to set log4j logging level is:
logger = Logger.getRootLogger(); // or Logger.getLogger("com.foo");
logger.setLevel(Level.ERROR);
This is standard log4j use, regardless of Lambda. A more Lambda-specific question might be how to control logging without changing your source code. Currently the best answer to that is using Lambda aliases, which would be clumsy, but soon Lambda will support environment variables as part of the function configuration and you could use that.
Each invocation will get three log lines from Lambda: START, END, and REPORT. All other log lines are from customer code (or modules used by customer code), or else a stack trace from an unhandled exception in user code, so it's up to you to control that.
You have to use the exception handling mechanism in your code. if any of error occur in your code then catch block should run and there you can use stacktrace methods for tracing the error. The stack trace method can be different in different languages.
For Cloudwatch log you can use simple console output methods according to languages.
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 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.
We've got an old legacy win32 service, developed with C++, and we've just recently noticed that when the service starts up and stops, there is an informational message in the event logs about our missing event descriptions. To be more precise, the message looks like this:
The description for Event ID 0 from source [application] cannot be
found. Either the component that raises this event is not installed on
your local computer or the installation is corrupted. You can install
or repair the component on the local computer.
So we understand what this means, basically we're missing a library which has a message table compiled into it. This way when the event ID for changing status (start/stop) arrives, it can look up the message and print it in the event logs.
The question is, for these universal messages (changing status etc) which pretty much every service is going to have, surely there are default message table that we can use, rather than having to go to the trouble of creating another project, just for this, adding registries and updating our installer.
Seems like a lot of hassle for something that should surely be a default somewhere? Like the standard win32 error messages?
I've created a number of managed services in the past, and I'm pretty sure we didn't need to do anything like this before!
So to wrap this up, I guess the answer is that the a new message table/file is always required, regardless (so no there are no default messages you can use), so I'll just have to chuck in a message table into my services resource file and add a registry entry to the installer.
Still find it baffling thought that every native service has it's own 'service has stopped/started' message...!
Thanks!