How about instead, logging the exact request that failed? Then, your server engineers can add it to their test suites, and you can use curl or wget to get the response, and add that response to your test suite.
What this lacks in tight coupling it more than makes up for by being a test that gets run repeatedly and isn't breakable. However, you really should *never* see this sort of problem. I can think of two likely explanations, both of which deserve more systematic responses than looking at an individual failing case: 1) The output is malformed XML. This should never happen, because your server engineers should not be attempting to format XML as text. They should be creating a DOM and using a standard seralialization API, or they should be using an event-based serialization. Trying to write correct XML "by hand" under all circumstances is both a formula for bugs and a whole lot of wasted work. And the resulting code is fragile and difficult to maintain! 2) The output is being truncated, due to bad error handling or IO handling on one side or the other or both. If you get an error in the middle of writing, you must close the connection. Ideally, you'd set the content-length header; that's not always possible for performance reasons. But far better than doing it in the middle of writing is to always do any work that might get an error before beginning to write. Then, you handle and ignore IO exceptions during write (because the connection failed -- a routine, expected occurrence that generally doesn't even warrant logging, though you'd like to detect abnormal frequency). Other exceptions, you return a suitable 5xx-category HTTP status, which the client should handle in some user-friendly way, whether that be to remain silent and try it again, or to gently explain to the user that he's totally, irreversibly had his life ruined forever. On the client side, IO exceptions are to be expected as well. If the IO exception is an end-of-file exception, the data is truncated. Finally -- make very sure that the server actually flushes all the output to the network before closing the connection! I'm not saying that logging responses that aren't what you expect isn't a good idea! But in my experience, it's far from essential, and should not form your main line of defense against bad responses. On Dec 1, 1:43 pm, Bret Foreman <[email protected]> wrote: > It turns out that markSupported() returns false so I'll have to > override the class and implement mark/reset. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
