better default exception strings

I'm getting a bunch of stack traces from an app (various OpenStack componentry) which end with the following message

```
ConnectionError: ('Connection aborted.', error(146, 'ECONNREFUSED'))
```

or something similar.  In all cases, the underlying problem is bad administrative configuration -- that is, not strictly a bug in either the app or in requests -- but the message is so vague that it's a huge pain in the ass to try to track down what it was trying to connect to when it failed.  Sometimes by looking at the stack trace I can figure out what it was trying to do, but not always.

I could go and patch the apps to catch exceptions from requests and have it print out the URL, but that's potentially a lot of places.  I was wondering if it would make sense to have a `__str__()` method for `RequestException` that would spit out the URL in addition to the basic junk from `IOError`.  I tried

```
def __str__(self):
    s = super(RequestException, self).__str__()
    return "%s: %s" % (self.request.url, s)
```

and it did what I expected, at least for the one test case of connecting to an unlistened-on port.

I'm not looking for end-user-appropriate strings like in issue #2876, but just something to help out a reasonably savvy administrator unscared of things like stack traces and other gobbledygook, but short on time and patience to go figure out what the software should be telling her anyway.

Obviously more information might be necessary to diagnose certain problems, since the problem might be related to the request data, or other possibly large data, which you almost certainly would never want to show by default, but usually the requested URL is a useful point of information.

Thoughts?


So, as a person who contributes to OpenStack, I'll say this:

The fact that you're seeing an exception from Requests is a serious problem. Whatever service you're using, might be logging these but should also be logging (with it) an explanation of what happened. Granted, it's OpenStack, so I really shouldn't expect that level of quality, but this is (in my opinion) more of a bug in whatever service caused you this grief than in Requests.

---

The above aside, I'm +0 on this. I really think our exception messages aren't ever meant for anyone other than the developer who is writing the application using requests, but I can imagine how this _might_ be useful. I'm not +1 on this because we've been trying to attach request objects to most of these errors as it is, so if developers are going to log Requests' exceptions they can display information about the request too.


I'm not averse to this in principle. I suspect we'll find getting this right across things like redirects is a bit tricky, but we can worry about that when we do it. If you want to submit a patch, @dhduvall, I'll review it. =)


I completely agree that the up-stack application should be doing a better job of handling exceptions.  But, like you, @sigmavirus24, I'm not about to expect that from OpenStack, and given how prevalent the problem is, it seems like some relief could be found in the common code, even if it's not an actual fix to the real bug(s) here.

There are a couple of exceptions raised that IMO should include the URL but don't, and don't provide a request object (`InvalidURL` instances seem to be where that would be the most useful). They should probably just have their message strings rewritten, but my initial attempt won't try to change that.