[seek-dev] What to do with Seek provider exceptions?

[Kevin Ruland]

Matt,

I completely agree with this.  There should probably be only be one
class of remotely generated fault with perhaps an embedded message which
could be used for diagnostics.  The message might indicate to the user
to retry at a later time, or give up hope completely.  An empty result
set should be returned only if the query succeeds successfully and there
are no results to return.

Digir poses some interesting situations because it is a proxy to
multiple preconfigured back end providers.

It could be that every back-end is down.  In this case technically the
query is well formed, but there was nobody to ask. 
<rhetorical-question>Would this be an error condition or a empty
result-set?</rhetorical-question>  Of course this would naturally be an
error condition because there is no assurance the result set would have
been empty or not.

Now suppose all but n of the back-ends are down, and none of these back
ends have records which match the query?  This one I'm not so sure
about.  Is the answer different if n is small or large?

Since I'm looking into this, there are a number of magical things which
are preventing soap faults from being generated -- down in EcogridUtils
and the o.e.e.queryservice.util parser/transformer code.

Kevin

Matt Jones wrote:

> Probably the only messages the user should see are 1) things they can
> do something about, and 2) things that might affect the quality of
> their search.  If they think the searched a data source but an error
> prevented that from happening, they should be notified.  The number of
> potential system errors is probably much greater than the number of
> appropriate user messages.
>
> Matt
>
> Kevin Ruland wrote:
>
>> Hi all,
>>
>> This question has probably been rehashed a number of times but I don't
>> really know where to look for the answer.  I
>> Is there any well defined category of exceptions which are to be
>> returned by the query service?  It seems right now, that almost every
>> problem in the digir server will end up returning a simple empty result
>> set.  This in most circumstances will not properly indicate a problem to
>> the user.
>>
>> What problems should come back as faults and which ones should be
>> hidden?
>>
>> Kevin
>> _______________________________________________
>> Seek-dev mailing list
>> Seek-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
>>
>