On Sat, 30 Nov 2002, Sascha Schumann wrote: > > > -1 on errno-style error codes. They are not versatile > > > enough or easy to manage. > > > > They are a lot more versatile and manageable than having to use > > substring/regexp matching on human-readable text. > > > > What I'm going for here is a way for scripts to detect _why_ fopen fails, > > other than checking the error message. If we do get localized error > > messages at one point, this is even more important. Do you have any other > > suggestions? > > In order to succeed over a long period of time, error tokens > need to be versatile enough to satisfy this set of > requirements. > > - the conflict potential should be low > (can conflicts between independently released modules be > avoided and if yes, how) > > - they should be easily recognizable by humans and automatons > (so that e.g. bugs.php.net can easily insert the English > error message for any given error code) > > - management overhead should be as low as possible > (do we need a central registry and to what extent) > > Could you explain how you think that errno-style codes > achieve these tasks?
Sascha, I asked if you had any suggestions because I really wanted to hear if you had any suggestions, not because I wanted to dive into a verbal trench war. It doesn't have to be errno-style error codes, as long as the solution has the right balance between completeness and simplicity to make sure that all extension and PEAR package maintainers start using them. But assuming that our goals are fairly similar after all, I take the liberty of re-phrasing your mail as two suggestions: 1. make a naming scheme for error codes/symbols that is scalable, easily machine readable but also human readable 2. partition the error symbol space with a resolution to optimize management overhead Are we on wavelength yet? - Stig -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
