@bdrosen96 : l wonder if you might need another test to further illustrate that these (different) C errors are being generated. The impression I would get from this test alone is that you were testing for an encoding error. @jreback what do you think?

Current coverage is 84.54%

Merging #13693 into master will decrease coverage by <.01%

@@             master     #13693   diff @@
==========================================
  Files           141        141          
  Lines         51185      51161    -24   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
- Hits          43275      43252    -23   
+ Misses         7910       7909     -1   
  Partials          0          0          

Powered by Codecov. Last updated by 506520b...0efe18b

With this fix, we get the same exception for both engines, where previously we got one exception for python engine and a different one for c engine (the cparser exception with no indication of the root cause of the failure)

I'm not sure what another deterministic stream error we could test here, unless we try to create a fake stream that errors after some number of bytes read.

fyi if you use the # on an issue it references automatically

@bdrosen : what I meant were there any other errors besides the encoding one that the C engine was previously swallowing that are now surfaced?

Just to emphasize: not a blocker, but a nice to have (i.e. a test for another error that was being swallowed)

Yes, there are other cases that would now be surfaced, but they would be hard to create a test for. For example:

1 HTTP request to get remote file as file like object (stream) passed to read-csv. Something goes wrong with network and exception is raised during read. We should now get a non generic error indicating network trouble rather than the generic read() error from before.

2 Same thing with FTP, HDFS, gluster, S3 or any other network type file operation.

3 Stream handle does decompression/unarchive (ie .csv.bz2 or .csv.gz, .csv.tar.gz, etc)

There are probably other cases that I am not aware of now.

@bdrosen96 actually could easily test a network op on a non-existant file (and even an s3 op for the same, just give an invalid bucket).

I don't think testing a network op on invalid bucket or non existant file would work since the exception would likely occur during open rather than read, so that would not help.

pls also add a whatsnew entry, you can put in API section as now better exceptions are passed thru the parser (plus I think the exception type could have changed), e.g. I think previously you would have gotten a CParserError (which is a ValueError), now you can get other things. If you can posit a useful message would be great.

Added whatsnew, closed codec recoder stream and added comment for test

thanks @bdrosen96