On 11/15/05, Kai Peters <[EMAIL PROTECTED]> wrote: > > Volker ~ > > I guess we have to agree to disagree then: > > For instance, your 'attempt solution' fails at > multiple results for multiple service requests ... > > [ > ok [time 25-Mar-2005/12:08:12-8:00] > ok [info "Default REBOL Service"] > fail [file/put not-allowed] > fail [file/get not-exists] > ] > > And no, I don't believe the fix is to break the code > above down into 4 single requests and wrap them in attempts. >
agreed. thought errors happen only with a single request, as mentioned in the docu. with multiple results i like an error too, but each response should be available. But how to return both? global is ugly. > Besides, to me it's just plain wrong - or would you accept a > SQL client library that coughed every time it received an empty > result set from the server? I dont like lazy errors where something goes wrong, is not handled and plays domino-errors later. an empty result-set in sql is no error. a missing file is. a sql-rebservice should return an empty block then. errors are easily catched. easier than checking a result actually. > > These things are not what I would consider > errors to be thrown - they are plain expectable results. > > My 0.02 > > Kai > > -- > > Why? if i dont miss something, thats like missing files, bad data > format etc is handled too? it throws an error, and if you dont like > it, use attempt[read something] > > -- > > -Volker > > > -- > To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject. > > -- -Volker "Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem." David Wheeler -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
