[physfs] PHYSFS_stat/HG & Numerical Errorcode

[Christoph Nelles]

Hi, 

On Thu, 18 Mar 2010 15:59:57 -0400, "Ryan C. Gordon" <icculus at icculus.org>
wrote:
> I sort of want to ditch the language stuff. Localization has been a 
> giant hassle, and I don't know that I really want to formalize it into 
> the API.

It's a nice to have and i think the messages should be distributed
centrally with physfs, perhaps in the extras folder. If everybody has to
localize the messages himself it's a lot of duplicate work. 

> My counter-proposal:
> - PhysicsFS will report error codes as enums. Your work here is 
> basically what I'm looking for, I think.

Enums make it easier for programming purposes, but text messages are more
useful for the application user. 

> - PHYSFS_getLastError() has always claimed that you can't trust the 
> strings it supplies (in that they aren't machine-readable, they can 
> change without warning, and they might be in any human language anyhow).

> I think we should deprecate this function. It will remain but only 
> supply english (or perhaps just stringified error codes, like 
> "ERR_OUT_OF_MEMORY"). The theory is that those that care can hook this 
> up to their app's localization routines, and these strings will be 
> consistent for translating, if they like.

That's the reason a more stable numeric error reporting is necessary. If
you deprecate this function you will break backward compatibility. 

> - Things that currently generate a dynamic error message (like 
> win32strerror() or zlib_error_string) will be changed to use some 
> generic, static error code (a generic "operating system error" or 
> whatever makes sense, if it's not reasonable to obtain a more 
> informative error message for a given operation).

I think a healthy trade-off between generalizated und specialized errors
is necessary, some errors need different handling. If you can distinguish
between n seek error due to going beyond EOF and an OS error it may be
helpful. Perhaps a set of really fatal errors (physfs corruption or so)
might be reasonable. 

> 
> The original thinking behind PHYSFS_getLastError() is that all errors 
> are basically fatal, so you should dump the error message to stdout and 
> quit, and let the user sort it out...this isn't a robust approach, so 
> cleaning this up is a good idea.

I don't think that all are fatal, some of them are recoverable or
ignorable if you know which error happened. A mildly seek error, a disk is
full error or access denied when writing savegames are not fatal enough too
kill an application instantly. In my opinion. 

-- 
Christoph Nelles

E-Mail    : evilazrael at evilazrael.de
Jabber    : eazrael at evilazrael.net      ICQ       : 78819723

PGP-Key   : ID 0x424FB55B on subkeys.pgp.net
            or http://evilazrael.net/pgp.txt