Yes, we're still trying to figure out the mechanism via which we want to handle such things. The big problem with returning error codes, etc. is that there's a strong tendency to ignore results than indicate an error. When potentially security-critical problems come up, I would rather just see the program die if there's any significant chance of the programmer failing to check the error condition and leaving the program in an insecure state. We are leaning toward providing a callback for when a "fatal" error occurs. The default will be to print an error message and abort. This solution gives the programmer some flexibility, and even avoids needlessly adding a bunch of additional error conditions to check. On the down side, it can be difficult to figure out the exact context of failure and recover gracefully. We'll definitely have some solution in place by the beta series. John On Tuesday, February 11, 2003, at 07:34 AM, Giorgio Zoppi (deneb) wrote: > A library when gets error conditions, should toss that error condition, > to the programmer. In that *alpha* code you assume that the programmer > is stupid, and kill the program when the string arrays aren't safe, > at least you should provide a way to check. > Cheers, > deneb. >
This archive was generated by hypermail 2b30 : Tue Feb 11 2003 - 09:34:26 PST