28.06.2014 12:38, Mark Rotteveel wrote:

> I am working on replacing the protocol implementation, and now I am
> running into a 'problem' with parsing the status vector (or actually
> with the result of that parse).
>
> Currently I treat each isc_arg_gds and isc_arg_warning as a separate
> exception that is chained to the previous exception, but it looks like
> the statusvector contains only a single error that is constructed from
> multipe isc_arg_* entries (including isc_arg_gds).
>
> Is this indeed the case, or can the status vector contain multiple
> independent errors? If so is there a way to identify when the next error
> starts?

Usually, the status vector has one error or a number of dependent errors 
(first one is primary and others are qualifying the primary one). 
Sometimes it contains errors that may look independent, but in fact 
they're dependent (one error may cause another one before being 
processed), however it could be hard to figure out.

> A separate problem is identifying the most specific error. I notice that
> the head of the status vector has the least specific error code (eg
> isc_dsql_error instead of isc_dsql_field_err for a "Column unknown") is
> there an algorithm to determine the most specific error code or do I
> need to apply some heuristic (eg if the errorcode is isc_dsql_error then
> use the next error code, or always use the last one).

I'm afraid only heuristics may help.


Dmitry


------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to