What steps will reproduce the problem?
1. Execute the /expand, /info and /stats methods using a non-existent hash as
the argument
(like 1234THISISFAKE4321).
2. Compare the results.
What is the expected output? What do you see instead?
I expected the error reporting to be consistent about these calls, as they all
deal with single or
batch requests, and they all operate on already-shortened URLs.
/info Behaves in what may be the most logical way. If the method itself
executes without error
(barring invalid results), no error is reported in the top-level error keys. If
the requested
hash/url doesn't exist, that error is reported within the relevant key (the
submitted hash/url)
using the familiar error keys. That seems the most logical to me because it
clearly shows two
possible levels of errors: API/method and then method arguments.
/expand Reports an error at the top level indicating the presence of an error
to be found in one
of the result sets (unless there is no error). This isn't crazy because the
code specifically
indicates that an error in the contained batch is present. The crazy part to me
is the
inconsistency with /info.
/stats Doesn't seem to report any errors at all, which to me seems just plain
wrong. If an invalid
hash/url is provided, I would expect a relevant error to be returned.
What version of the product are you using? On what operating system?
2.1 - any
Original issue reported on code.google.com by ch...@rosaloves.com on 2 Mar 2009 at 9:05
Original issue reported on code.google.com by
ch...@rosaloves.com
on 2 Mar 2009 at 9:05