[physfs] PHYSFS_stat/HG & Numerical Errorcode
Ryan C. Gordon
icculus at icculus.org
Thu Mar 18 15:59:57 EDT 2010
> As you take this work so lightly could you please take a look at my
> ErrorCode branch and tell me if you like the idea? It's a work in
> progress and i've made a few new files so i have a clearer work area,
> they can be merged later.
Here are my thoughts:
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.
My counter-proposal:
- PhysicsFS will report error codes as enums. Your work here is
basically what I'm looking for, I think.
- 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.
- 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).
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.
--ryan.
More information about the physfs
mailing list