On Sat, Mar 13, 2010 at 11:07 AM, John Locke <[email protected]> wrote: > I'm not a big fan of error codes, and coding modules so that casual > programmers not familiar with the codebase have to go hunt around to > find the source of the issue... well, ugh.
The idea of error codes is to solve a different set of problems (and no, we would never log just the error code): 1) It allows for a machine-readable representation of the error code for additional diagnostics and reporting. 2) Several error codes could, in theory, share the same error message. We may want to present only the error message to the user, but log both the code and extended information for the administrator. For example, in 1.3, if a statement throws a SQL State of either 42501 or 42401, we show an access denied message, and we log the complete error message from PostgreSQL along with the SQL state code to the error log. From the stored procedure module, I would assume the error id would be the SQL state. Unknown SQL states throw an error to the user, log the full information to the log files, and include the SQL State. In part this is so that we can accept feedback on how to handle specific errors better. The error id would never be the means for system administrators to try to troubleshoot an error. It would be specifically for programmatic handling of specific error conditions. > > I'd like to be able to see from the exception what module threw it, > where in the code it was, and what triggered it. yep, that's the stack trace. But in addition we would like to tell you the error message itself, and any extended information that might be understood to be helpful. > If that's in the stack > trace, and the stack trace is easy to enable, fine. I just don't want to > have to open some other reference to figure out what error -69 in module > 0xD4 is, or where it came from, even if I have the stack trace disabled. > I'd like to see filename/stored function name, line number, string > message, severity if nothing else. Type contains severity information. The module will be changed to the module namespace, and the stack trace will ignore calls inside the error handling packages (for ease of understanding). Enabling the stack trace would be done in the application's main config file. Best Wishes, Chris Travers ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
