On Mon, Jun 27, 2016, at 12:40, Ethan Furman wrote: > On 06/21/2016 01:48 PM, Serhiy Storchaka wrote: > > > There is a design question. If you read file in some format or with some > > protocol, and the data is ended unexpectedly, when to use general > > EOFError exception and when to use format/protocol specific exception? > > I believe that EOFError was created for the situation when a file > unexpectedly ends. The problem is that's not a good abstraction for the class of errors we're discussing, because it means you've got to pick: the thing your parser parses is a file [and non-files are supported by wrapping them in a StringIO/BytesIO] or it is a str/bytes [and files are supported by reading their data into a string]. Or you could use a third option: a method that accepts a file raises EOFError, and a method that accepts a string raises some other error (ValueError?), and if either is implemented in terms of the other it's got to wrap the exception. (Also, that's nonsense. EOFError is also used when a file *expectedly* ends - EAFP i.e. "Exceptions As Flow-control is Pythonic" ;)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4