I'm a bit confused...
I have a webapp exposing soap webservices.
Now I need my ws's clients to get exception my ws methods are generating (custom exceptions and generic exceptions like Hibernate Exception and so on).
I read a lot but I can't figure out a good solution for... can you please indicate me the best way for this?
Related
My goal is to come up with a set of automated tests that will consume some services of an API and check if the compatibility is not broken (by mistake or on purpose).
My initial idea is to get the JSON results and deserialize against the DTOs used in the serialization. The reason is to avoid the manual generation of a schema that can get really big and difficult to maintain. The problem is that libraries like GSON are very robust and tend not to thrown exceptions when some problem happens in the deserialization (unless we write a custom deserializer, that again will take time and maintainance efforts).
Am I going in the right direction here? or is there another way to ensure API compatibility?
(Ideally, I would like to test not only JSON, but also XML responses from the same API.)
I am a newbie in grails and trying to find a best way for exception handling in Grails.
I am using Grails 2.4.2 with Spring Secxurity Core.
Following are the scenarios that needs to be considered.
Call to the Grails app could be Web Call/Ajax call/ RestFul call.
Response type expected could be a JSON/TEXT/XML/HTML
Exceptions could occur in any layer of the application(Filters, COntrollers, Service, Domain, TagLib, Database)
Proper HTTP Status code has to be set for the exception. (Could be same for all exceptions)
I want to have a least impact on the coding since grails reduces the boiler plate code a lot, i don't want to end up writing redundant codes in each controller.
Consider the above scenario's what could be the best possible approach on this.
Based on the format type( Content-Negotiation in Grails we could determine the Response Type that is to be provided). I was looking at the traits way of adding exception handling in the controller by implementing the traits for all controllers as defined in the Grails User Documentation. What would happen to the security exceptions that is being thrown by the Spring-Security.
When i make Ajax calls, I believe the error call back on the ajax client is determined by the status code of the HTTP Response code.
What I need is a way to forward any exceptions that occur to a generic error controller which should have access to the root cause, any messages associated with it and construct a HTML/TEXT/JSON/XML response out of it and render it to the client.
Is it possible to achieve this. Any inputs are highly appreciated.
Thanks in advance
I am using Enterprise Library's DAAB to access a database, both with ExecuteReader and ExecuteNonQuery. The problem is that these methods do not have exceptions thrown documented... How can I, then, know which exceptions should I catch?
I agree with WebTurner, I'm guessing a good place to start would be which database your connecting to, so if an ms sql database I'm guessing a couple of (perhaps many) exceptions would be:
SqlException
InvalidOperationException
http://msdn.microsoft.com/en-us/library/9kcbe65k.aspx
EDIT:
I just came across this: How can I determine which exceptions can be thrown by a given method?
Which looks liek it uses reflection to help uncover a list of exceptions that are thrown.
The problem is that there are many exceptions that will be thrown at a lower level than the enterprise library, and it would be impossible for EL to document all of these.
I suggest you use the exception handling and logging blocks to catch and log all exceptions. You can then see which ones occur and adapt the configuration of the exception handler or add new code to handle the specific execptions.
I need some direction how to best use Exceptions in a Java EE environment, serving clients via JAX-RS.
At the moment, I have a number of exceptions, all extending RuntimeException, and annotated with #ApplicationException(rollback=false). In order to transport them to the clients, they carry a JAXB-annotated entity; and an ExceptionMapper is ready to convert them to proper, meaningful HTTP Responses (HTTP Status codes included).
I have nothing specified regarding transactional behaviour, so I guess it defaults to CMT.
Great stuff so far: when the server decides, it cannot fulfill a request, because input data is not valid/sufficient/whatever, it throws one of my BadRequestException, which makes it to the JAX-RS resource, where it gets mapped to a HTTP Response. Client is informed about what went wrong.
The issue I have is that I always get a javax.ejb.TransactionRolledbackLocalException, caused by BadRequestException! I don't want the transaction to be rolled back! The #ApplicationException seems to be ignored...
Should I not extend from RuntimeException but rather use checked exceptions? I though #ApplicationException was supposed to be the right way...
For background information: all of my Exceptions leave the container/beans in a working state. No need for the bean instance to be destroyed or stuff like that.
For others struggling with same problem:
Annotation #ApplicationException is ignored(Not scanned/not processed) when Exception class is not included in ejb-jar. That is a common case when our ApplicationException is a part of API jar. In that case we have to use XML descriptor to mark ApplicationException.
Looking here helped me -> https://www.java.net//node/665096
Ok, turns out reading the manuals does help sometimes :).
An #ApplicationException is by definition not a RuntimeException. In fact, throwing RuntimeExceptions seems to be a very bad idea, that's what'll tear down a bean instance, rollback transactions, etc.
After switching everything to be based on checked Exceptions, my code not only looks much better, the IDE supports me much better as well. And it works like a charm. Now I can control, if my ApplicationException should cause transaction rollback or not.
I found this link useful, even though it describes it for Bea Weblogic.
Let's pretend for a moment that I have an application which has the following layers: a UI, Controller, Business Logic, and Data Access layer. The UI talks to the Controller, the Controller talks to the Business Logic, and the Business Logic talks to the Data Access layer. Let's also pretend I have a table in the database that houses error messages and exceptions that the administrator can use to troubleshoot problems with the application.
If a SQL exception is thrown in the Data Access Layer (e.g. there is a network issue, string would be truncated, etc.), how far up should the exception information make it before being logged? Ideally the log would contain messages from various layers that would give enough information for a developer to track down the issue. Is it OK for a SQL exception in the Data Access layer to get tossed all the way up to the UI and logged there? Or should it be caught locally, logged, and either rethrown or wrapped in another custom exception? Or should the Data Access layer return a special type that has a flag indicating whether there was an issue, and if so, it also attaches exception information. Also, is it a security concern for SQL exception/stack trace information to make it as far as the UI?
I realize this might be a little subjective for a questions but I'm curious as to what the experts say. Please let me know if you need clarification.
No exception should escape out of the service layer. If you remove the UI, wouldn't you want the services to still be functional?
This also makes sense because it's easy to put your logging into aspects and apply them declaratively to the service interfaces.
You can wrap and rethrow if the custom exception adds value.