On Sep 26, 2017, at 2:08 PM, Scott Robison <sc...@casaderobison.com> wrote:
> There are physical errors and there are logical errors. If an error is > generated from write, it's not unreasonable to classify it as an > "output error". From read as an "input error". "Output error", yes, although it'd be useful to provide more information. "Disk I/O error", no; it'd be unreasonable to classify "out of file system free space", "over quota", "permission error", "file bigger than 2GB-1 bytes", etc. as "disk I/O errors". > There is a lot of sqlite source code that already exists and has been > written to work with the current interface. That's probably one of the > reasons why extended errors were created, to provide finer > granularity. Regardless of whether it is ideal or not, changing sqlite > in a way that would break existing code is unlikely to happen. I was not suggesting that. I didn't suggest adding SQLITE_OVERQUOTA or SQLITE_WRITE_PERMISSION_ERROR. > Ultimately it doesn't matter when error codes were added to a given > operating system or which predates what. A decision was made in the > past. The options are to live with decisions that were made in the > past (one I've seen espoused multiple times in this mailing list), > come up with an approach that allows old code to work but exposes new > information (probably the genesis of extended error codes), or break > older code (which I've not seen done deliberately). I'm advocating a better version of the second of those choices than the current "here's the raw operating system error code" version that's currently provided. (sqlite3_system_errno() also has the problem that if SQLITE_IOERR is provided for something *other* than a failure that provides a system errno value, it doesn't do the job.) > That being said, I don't know any non-technical users who are going to > panic that IOERR means their hard drive is dying specifically because > of that text being displayed. Panic perhaps, but not that a hard drive > is about to die. Most people I know don't have that level of > understanding to correlate IO / ERR / hard drive failure rates. They don't treat "disk I/O error" as an indication that their disk is having a problem? That doesn't need an understanding of hard drive failure rates. I have no reason to dismiss the original writer's notion that "disk I/O error" might "[scare] the hell out of the poor sysadmin who suspects a filesystem corruption might be going on". > They > just think the stupid program is broken and not letting them get their > work done. As for the experienced technical people I know (or at least > me), their first thought would be to investigate the problem, not to > assume their hard drive is failing. Less investigative work is needed if the software gives a more detailed error report. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
