How can we create a throttling exception easily, in a cost effective manner, in sql azure? This is to test the TransientFaultHandling libraries in windows azure.
Found a way! create a mock class derived from ITransientErrorDetectionStrategy and return true. Use this class in
var retryPolicy = new RetryPolicy<MockClass>(retryStrategy);
That is it! No need to create a genuine throttling exception. for more..
Related
When there is some internal exception in a Webflux application, why do I want/need to write code to handle these exceptions? I understand handling issues and returning appropriate ServerResponse bodies when the service client incorrectly invokes a service, or when a non-error-condition (i.e., query returns empty cursor, etc.) occurs.
But, other than generating debug information into a logfile, is there anything to be gained by rolling-your-own exception handling components? This approach makes "more sense" to me in a monolithic application, where one is trying to avoid a scenario where the app "just dies".
But, for a service implementation, especially if there's some incentive not to expose too much about the internal implementation to a client, why wouldn't Spring's default error/exception handling (and "500 Internal Server Error" response/message) be sufficient.
So, after some time and thought (and little, but still helpful-and-appreciated feedback), I guess it boils down to:
(a) - It provides a localized context to "do things", like logging information about the exception/error condition, or categorizing the severity of the exception within-the-context of a server-client interaction.
(b) - It provides a localized context to hide/expose information from a client, based on the nature of the exception/error condition and whether the server is deployed in a production or test environment.
(c) - Being localized, it makes maintenance/modification a bit easier, as the handling of exceptions/errors is not scattered throughout the code.
(a) and (c) are enough to make me believe it's worth the effort.
I work on a multi tenant application. Current Tenant information is managed via thread locals, which are set via a filter for the request.
During integration tests (non-web) this filter does not apply, so I look for a method to set this thread local for unit tests.
I started thinking about an annotation on the test-class or methods (including #Before and #After). This could be something like #AsTenant("tenantId") (lets assume we only need the tenant id).
I basically look for a way now to extend SpringJUnit4ClassRunner to be aware of the annotations and properly set the thread locals at the right time. Does anybody have experience or ideas on where to hook this? (I am not very familiar with test runners)
Thanks in advance!
I have a JUnit project with 100s of lines of code and 100s of test cases already automated. But this project does not have any exceptions managed code. Hence while running the test cases from Eclipse, if there was an exception like NullPointer, etc, the execution halts in Eclipse with the error message of the Exception. I would like to handle these unhandled Exceptions in my project so that these messages are logged. Is there an option to handle these exceptions globally which I can setup for this project. Since it has 100s of methods it would be difficult to add exceptions for each and every method that already exists.
My project runs in Java 7 + JUnit 4
Any pointers will of great help. Thanks in advance!
Update 1:
I found a solution by creating a class that implements TestRule. But in order to get this working, I will have to add #Rule statements in all of my existing test scripts which are 100s of files.
Is there a work around for this so that i can avoid editing all those 100s test scripts.
Regards,
Janaki
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 have several service classes that have static methods and offer a service to the rest of my program. Most of these services involve accessing an instance of SqlDataContext (linq2sql).
First I tried instantiating this connection as a static private member per service class.
This works, but it also generates a bunch of lock ups, delays and dirty object problems.
Now I went with a private instance that gets instantiated at method level. This works better in terms of lock ups and problems with dirty objects because the scope is smaller and more predictable, but this also generates a bunch of overhead in terms of connection handshakes.
How do you suggest to take on this problem?
Take a look at this article by Rick Strahl - he explains the options and provides a good factory implementation to cope with creating a single request per web context/thread (depending on what you are working in.
Used this in most of the applications I have worked on where we used linq-to-sql and it seemed the right approach!