Why does read-from-string signal an end-of-file error even when I pass the eof-error-p argument as nil?
According to the ANSI spec, a null eof-error-p argument suppresses an end-of-file condition that occurs just before reading a new object, but NOT one that occurs while in the middle of reading an object. Reading from the string “(foo”, for example, will still signal an error at end of file, because it is in the middle of reading a list object at the time. Here’s a rule of thumb to follow: If you know that a string is “well formed”, such that a sequence of valid objects can be read from it in the usual iterative way with an end of file immediately afterward, then you can rely on a null eof-error-p argument to avoid signaling an end-of-file error. But in the general case where a string has unknown contents, an end-of-file error (or some other read error such as “too many colons”) may still be signaled. Generally when reading from unknown contents, it’s a good idea to wrap a handler-case form around the read to trap errors. Here is the relevant text from the ANSI page for read-from-string
Related Questions
- When we try to start the vendor daemon, we get the error: (cameo) tcp_s is bad!!! Exiting (cameo) EXITING DUE TO SIGNAL 28 Exit reason 5 How to start the license server?
- Why does read-from-string signal an end-of-file error even when I pass the eof-error-p argument as nil?
- Are hardware signal lines (DTR/DSR, RTS/CTS, RING, ERROR, DCD, etc.) emulated in Virtual Modem PRO?
