[physfs] PHYSFS_stat/HG & Numerical Errorcode

[Indy Sams]

Hello Ryan,

      I like this idea with the enums, but I would make PHYSFS_getLastError() return real error messages though instead
      of strings for localization (even if you remove all the existing localizations and just use English). That way people can use the enums to localize if they want while still having meaningful error messages for those that just want to use _getLastError().

	For dynamically generated errors like zlib_error_string, you could just set an enum value like ERR_ZLIB_ERROR or more generically ERR_LIBRARY_ERROR or something like that and people can either show a generic message based on the enum or the dynamic error text with _getLastError(). For convenience all the errors codes that have dynamic errors could be placed at the end of the enum so programs can easily determine if a certain error code uses static or dynamic error text.

	Since all the strings already exist, this wouldn't add a lot of extra work I don't think while still giving people an easy way to display errors but giving them the option of localizing if they want in a standardized way.

Thursday, March 18, 2010, 3:59:57 PM, you wrote:


>> 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.

RCG> Here are my thoughts:

RCG> I sort of want to ditch the language stuff. Localization has been a 
RCG> giant hassle, and I don't know that I really want to formalize it into
RCG> the API.

RCG> My counter-proposal:
RCG> - PhysicsFS will report error codes as enums. Your work here is 
RCG> basically what I'm looking for, I think.
RCG> - PHYSFS_getLastError() has always claimed that you can't trust the 
RCG> strings it supplies (in that they aren't machine-readable, they can 
RCG> change without warning, and they might be in any human language anyhow).
RCG> I think we should deprecate this function. It will remain but only 
RCG> supply english (or perhaps just stringified error codes, like 
RCG> "ERR_OUT_OF_MEMORY"). The theory is that those that care can hook this
RCG> up to their app's localization routines, and these strings will be 
RCG> consistent for translating, if they like.
RCG> - Things that currently generate a dynamic error message (like 
RCG> win32strerror() or zlib_error_string) will be changed to use some 
RCG> generic, static error code (a generic "operating system error" or 
RCG> whatever makes sense, if it's not reasonable to obtain a more 
RCG> informative error message for a given operation).

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

RCG> --ryan.

RCG> _______________________________________________
RCG> physfs mailing list
RCG> physfs at icculus.org
RCG> http://icculus.org/mailman/listinfo/physfs


Best regards,
 Indy Sams
 mailto:indy at driftsolutions.com

 P.S. This is what part of the alphabet would look like if Q & R were eliminated.