[physfs] PHYSFS_stat/HG & Numerical Errorcode
evilazrael at evilazrael.de
Fri Mar 19 05:00:22 EDT 2010
On Thu, 18 Mar 2010 15:59:57 -0400, "Ryan C. Gordon" <icculus at icculus.org>
> 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.
E-Mail : evilazrael at evilazrael.de
Jabber : eazrael at evilazrael.net ICQ : 78819723
PGP-Key : ID 0x424FB55B on subkeys.pgp.net
More information about the physfs