Wooooo
Every one is going in different directions and it's my fault:-)
Greg Hudson wrote:
>On Tue, 2002-12-10 at 12:20, Glenn A. Thompson wrote:
>
>
>>I understand his point. But I won't be putting Oracle or MySQL error
>>codes into APR space. I think it would be confusing. Often times, n
>>number of errors can be treated as a single condition. That doesn't
>>mean I want to lose the granularity/information altogether.
>>
>>
>
>In the general case, the fine-grained information in a third-party error
>might be more complicated than a single integer. So if we want an
>svn_error_t to contain this information (and I'm not sure we do),
>src_err isn't a very good way of doing it.
>
>
I do and I agree tha src_err isn't a great way of doing it. Put simply,
it's the way it *was* being done. So I used it in the SQL support
classes I'm developing.
>
>
>>The bottom line is that I'm OK with the change. If I need this type of
>>behavior, and I think I will I'll just create an ERROR code like I
>>mentioned in my later e-mail response.
>>
>>
>
>I don't quite understand this proposal. If you mean that there would be
>an APR error code which says "child->apr_err is a third-party package's
>error code," then I find that hackish.
>
>
I'm saying that if I need to stash some fine-grained error codes I will
simply have an svn error code where I know how to parse the message.
svn_error_create (GENRAL_FS_ERROR,0,
svn_error_create(SVN_DB_INTERNAL_ERROR,0,NULL,"ORA-0001"), "Badness
occurred");
And yes it is hackish. I think I would prefer a separate function to
set (void) user_data on the error. I thinks it's more clear. As I
understand it, marshaling this over the various layers becomes a little
ugly. So, do what you need to do to clean that up. I'll make due.
>I also don't understand the case for error-handling callbacks. If an
>error requires special processing by an inner module, why not perform
>that processing before passing back the error in the first place?
>
>
>
Because sometimes ordering of error handling is important. The
framework needs to do something before the specific impl does his thing.
If the framework is driving the boat, the impl may need to stash some
opaque data in the error structure for a later callback.
But I'm done not making my point:-) We could go all day on theory. But
I've only given myself 2 hours a day for Subversion right now. I'd like
to use them breaking down my patch:-)
You asked for comments on the src_err field. It isn't what I prefer but
it did provide me some value in my undelivered code. I have another way
to do it.
I will do that. I can't vote anyway. I've spent enough of everyone's time.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 10 19:35:31 2002