Re: Tests hanging - any hints?

[Francois Orsini]

I don't know but I have been looking at this for another fix - I don't understand why the whole exception (with chained esceptions) is *not* built on the client-side when the original exception is raised, rather than going and fetch corresponding server information on demand as a SQLException is being accessed - seems to me not that optimal but there might be a good reason for this - we don't really need to save network traffic in some exception code path - it is not the most common case for sure but again there could be some other reasons for this...I think the original exception with its chained exceptions should be generated on the client side when the exception is detected in the first place...I believe this is the same for (chained) SQLWarnings...

--francois

On 1/19/06, David W. Van Couvering <[EMAIL PROTECTED]> wrote:

It seems odd (and somewhat dangerous) to me to be doing network I/O as
part of exception processing.  Easy to get an error within an error (I
even saw some gnarly code in the log tracing code on the client to make
sure that stuff wasn't pulled over to avoid just such an error within an
error scenario).

What was worse is I didn't even get an error -- just a hang.  Seems like
a pretty sensitive protocol to me :(

Is there any reason why the message text isn't sent over ahead of time
as part of the original exception message sent from the server?  I don't
see the value in saving network traffic when you are in an exception
path.  Is it because many exceptions get ignored/handled without being
reported to the user?  Anybody know the history/motivation behind this?

Thanks,

David

Bryan Pendleton wrote:
> David W. Van Couvering wrote:
>
>> Thanks to both Brian and Dyre for their tips.  The patch for Brian's
>> bug didn't help, but both your emails got me thinking and I discovered
>> I was getting info out of the SQLCA structure earlier than the code
>> used to do, and I think this was incorrectly trying to pull
>> information over the server.
>
>
> This makes sense. The exception processing in the client/server case is
> interesting, because the client-side SQLException classes have methods in
> them which go across the network to fetch server information.
>
> For example, calling "getMessage" on a SQL Exception in the client may
> result
> in network calls to fetch the correctly-localized text from the server. It
> generates a call to a system procedure, I believe. There was some
> conversation
> about this on the mailing list a few months back because I was
> investigating
> a bug in which the getMessage() result is truncated in client/server cases
> due to a hard limit on the output parameter length in this system
> procedure.
>
> So if you were changing the implementation of the SQL Exception handling,
> you definitely could have interacted with this code.
>
> Glad you resolved it.
>
> bryan
>
>
>