Re: Error Handling in 2.0

[Chris Travers <..hidden..>]

On Sat, Mar 13, 2010 at 11:20 AM, Luke <..hidden..> wrote:
> On Sat, 13 Mar 2010, Chris Travers wrote:
>
>> 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.
>
> I actually think the hex idea is the right one, provided that the display
> code can look it up and append the user-comprehensible module name.

No reason we can't do both.  I would be willing to bet we can automate
the package namespace that called the error so we don't have to make
every caller do that manually.

Best Wishes,
Chris Travers

> My thinking is that you could conceivably run into a circumstance where
> the module name is ambiguous, whereas a module ID of some kind would be
> unique.  Also, in bug reporting, if you have several potential modules
> with one name, it might be useful to differentiate.
>
>> 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.
>
> Seems reasonable.
>
> Luke
>
> ------------------------------------------------------------------------------
> 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
>