Re: Error Handling in 2.0

[John Locke <..hidden..>]

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.

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. 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.

Cheers,
John

-------- Original Message  --------
Subject: Re: [Ledger-smb-devel] Error Handling in 2.0
From: Chris Travers <..hidden..>
To: Development discussion for LedgerSMB
<..hidden..>
Date: Sat 13 Mar 2010 10:56:43 AM PST
> On Sat, Mar 13, 2010 at 10:46 AM, John Locke <..hidden..> wrote:
>   
>> Ok this might be a dumb noob question, but why use some hexadecimal
>> notation of the module? Why not just the string module name?
>>     
>
> I was thinking about having a much more compact error notation.  Maybe
> the namespace it is called from would be a good thing to use instead
> though.
>
> As for the error ID, I am wondering if it might be better to use a
> short string as well.  That way we could use SQL State codes as error
> id's as well.
>
> Best Wishes,
> Chris Travers
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>