[SAGA-RG] missing(?) method reporting last modification time

Andre Merzky andre at merzky.net
Thu Sep 24 09:29:00 CDT 2009


Quoting [Sylvain Reynaud] (Sep 24 2009):
>> 
>> Is your use case different from those cases where one could
>> delay error reporting, too?  If so, how?
>> 
>> 
>> Or positively speaking:
>> 
>> If there is a reason why async operations won't work,
>
> It would work, but it is still useless messages sent to the server...

Ah, ok - but then we are talking about bandwidth, and
fairly small bandwidth, too.

>> But then again, introducing a general flag for delaying
>> errors is quite a significant semantic change, really.
>> FWIW, Hartmut (and someone else, can't remember) brought
>> that topic up a while ago, when wondering if SAGA calls
>> should not be getting an optional additional parameter to be
>> returned on any errors, like
>> 
>>   // standard SAGA call 
>>   size_t s = file.get_size (); // can throw
>>   std::cout << "size: " << s << "\n";
>> 
>>   // error ignoring SAGA call
>>   size_t s = file.get_size (0); // never throws
>>   if ( s == 0 ) std::cout << "size: Unknown\n;"
>> 
>> The proposed signature change would basically allow for SAGA
>> calls which never throw, no matter the error condition.
>
> I don't see any reason for doing this, since the user can always catch 
> the exception if he/she wants to ignore the error.

Well, the same can be said for your use case.  The reason is
caching, and delayed execution.  The example above may be
misleading, I agree.  But consider a file.open(), or
file.copy(), which basically has the same semantics as the
file constructor. 

> What I would like to do is not to ignore errors that have already been 
> detected, but to disable preliminary checks when needed.

It depends on the use case which checks are preliminary.
For your UC it is file existence.  For another use case it
may be file read permissions.  Yet another UC may be job
submission permission.  Or if a stream can in fact connect
to a port.  Or if an RPC endpoint really exists and can be
used.  These are all checks which are implied for various
SAGA object constructors...

That is why I am hesitant to add it do the spec, and then
describe the flag as 'don't check for file existence',
because someone else  will come and ask for a different
check to be disabled for sure.  Bottomless pit ;-)


>> Bottom line:  An IgnoreDoesNotExistException (which your
>> 'MissingOK' basically translates to) sounds a very
>> specific flag, for a very specific use case.  Do
>> asynchronous operations help? 
>
> Better than synchronous, but still not optimal...
> 
>> If not, should we consider a DelayErrors flag, possibly
>> for the next SAGA version?
>
> 'DelayErrors' sounds good to me.

Ok, great - then lets stick to that name.  But I'd rather
move that to the next version, unless it is a no-go for you.

Any opinion from the others?

Cheers, Andre.


-- 
Nothing is ever easy.


More information about the saga-rg mailing list