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.