Avnish1985 / bitly-api

Automatically exported from code.google.com/p/bitly-api
0 stars 0 forks source link

Inconsistencies in error reporting #3

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago

Original comment by jehiah on 1 Dec 2009 at 11:31

GoogleCodeExporter commented 8 years ago
this is now fixed with the release of v3 bit.ly api

Original comment by jehiah on 30 Mar 2010 at 8:45