D. Richard Hipp wrote: > > Consider what happens if an interaction with the library contains two > or more errors. Only a single error message and error code can be > returned. Consequently, if the interaction contains error A we cannot > guarantee that the code and message returned will refer to A, since it > might instead refer to error B. We can guarantee that some kind of > error will be returned. We just cannot guarantee what the error code > and message content will be since that depends on what other errors > might be present. >
While that may be a concern in the most general sense, I don't think it is a valid reason not to document the error that is returned when a specific rule is broken. Take this rule for example: H42334: The preparation of a CREATE TABLE statement shall fail with an error if the the databasename references a database that is not attached to the same database connection. This is a very specific rule. There should be a well documented error that will be returned if this rule is broken. With these definitions in place, a user could search through the documentation and find all the possible causes of that particular error (heck, you might even want to create an cross reference list to make this step easier). This would often help them to locate the cause of the problem or suggest possible causes that they might not otherwise consider. The fact that multiple rules might be broken by a statement isn't really an issue since you do not (and should not) specify the order that the rules are checked. If a statement has multiple problems they may need to be fixed one at a time until they are all resolved. Giving users the best possible guidance at each step is important and valuable. Furthermore, there are other, non-rule based issues, such as "out of memory" or "I/O error" that may cause an API function to fail. The mere existence of such possibilities should not be grounds to avoid documenting the errors that are returned when any of the many rule based errors conditions occur. Dennis Cote _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
