> Thomas Lockhart <[EMAIL PROTECTED]> writes: > > I'm with Peter on this one. I'd like to *not* clutter up the code and > > error reporting with hints and suggestions which may or may not be to > > the point. > > We *should* have docs which list error messages and possible solutions, > > and throwing that info into code is a poor second choice imho. > > While you have a point in the abstract, a big difficulty is that the > docs never track the code with any accuracy. Look at the "Outputs" > portions of our existing reference pages. To the extent that they > describe possible errors at all, the information is a sad joke: out of > date in most cases, certainly incomplete in every case. Just last week > I was thinking that we should rip all that stuff out, rather than > pretend it is or ever will be accurate.
I recommend tips when they are one line in length, have a high probability of being accurate, and are common mistakes. Anything longer and we should point to a specific section in the docs. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
