Re: Error Handling in 2.0

[Chris Travers <..hidden..>]

On Sat, Mar 13, 2010 at 11:07 AM, John Locke <..hidden..> 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