Invalid ~/.netrc file does not raise any warnings or errors from requests

I end-up with a case where requests behaves very strange, because it does not load the credentials from .netrc file and it's extremely hard to discover when is using credentials and where is taking them from. 

The debug level output is identical in all 3 cases: no auth, auth from netrc or auth manually specified.


I've explained to you, at least twice ([1st](https://github.com/kennethreitz/requests/issues/1297#issuecomment-16130288), [2nd](https://github.com/kennethreitz/requests/pull/1302#commitcomment-2984789)) that requests performs **no logging** whatsoever. With those reminders brought up, I'll reiterate once more that requests will not and does not perform any logging.

If you want to, you can monkey-patch `requests.utils.get_netrc_auth` so that it will perform logging for you. Otherwise, you'll have to reason about the conditions [here](https://github.com/kennethreitz/requests/blob/0eb6dc36f088e6e5c0baaac3334dc5f0e4f07942/requests/sessions.py#L275).


Probably it is useless to ask for proper logging in requests so I will skip to the point: with debugging I discovered that the .netrc file stopped working because one new line couldn't be parsed by requests.

This new line was not related to the one that was supposed to be loaded but the way it is implemented the parsing fails and no information is loaded from the file (strange!?). In fact the desired line was before the parse errors one.

Also, there is zero information regarding the failure to parse the .netrc file.

In case you would wonder add a line like "machine example.com john johnpass" to the end of the file and .netrc will stop working with requests, it will still be loadable by other tools like `curl` or `wget`.


We don't parse `netrc` files ourselves, we use the standard library `netrc` library to do it. Check the function [here](https://github.com/kennethreitz/requests/blob/master/requests/utils.py#L67-L102), and confirm whether it works on your system.


In this case there are 1½ bugs here: requests does silently bypass any error in parsing .netrc (which it shoudn't), and ½ bug inside netrc in stdlib, which fails to load if parsing one line fails (other tools do not).


@ssbarnea That's interesting, you seem to have contradictory views about these two issues. In the first case, we're continuing in the face of errors, which you deem to be a bug. In the second case, Python aborts in the face of errors, which you deem to be a bug.

Furthermore, if you fixed the second issue (Python does not fail loading netrc if parsing one line fails), Requests will never silently bypass errors in parsing `.netrc` because it will never find out about those errors!

I'm +0 on the idea of no longer catching the `Netrc` exception. We could do it. Some people will find unexpected failures because they've never noticed that they even had anything in `.netrc`, but they'll be able to fix that in time. However, we certainly can't do it until at least 2.2, because we cannot start throwing exceptions where previously we worked just fine.


> Furthermore, if you fixed the second issue (Python does not fail loading netrc if parsing one line fails), Requests will never silently bypass errors in parsing .netrc because it will never find out about those errors!

Yeah this sounds like a bug that should be reported on bugs.python.org. The fact that we catch an exception is not an issue since we shouldn't be bubbling up exceptions especially if we can't be certain the user wants us to be using their `.netrc` file.

I'm -0 on the idea of allowing it to bubble up though.

That aside, I'm :+1: on closing this issue since the work to stop catching that exception is trivial.


Guys, thank you for your help. I would vote for raising the exception in at future release. It's quite easy to fix such a problem if the user sees the problem. Also, I will raise a python bug regarding the parsing.

`.netrc` is a wonderful thing and I like the default behavior of using it if it exists, the only remark was that if it is invalid it doesn't say anything. Imagine that I am calling some 3rd party libraries that do also work with anonymous but they return different results... it took me some time to find the cause.