Negative

[Carlos Santander]

Andrew Fedoniouk escribió:
> Hi, Carlos
> 
> "Carlos Santander" <csantander619 at gmail.com> wrote in message 
> news:dtvtgt$2mvh$1 at digitaldaemon.com...
>> Andrew Fedoniouk escribió:
>>> This is real life example:
>>>
>>> Logger log = getLogger();
>>> try {
>>>       File outf = getOutputFile(); // state managed outside
>>>       File inf = getInputFile(); // state managed outside
>>>       File tmpf = createTempFile();
>>>       // lots of code
>>> } catch (Object e)  {
>>>       log.logFailure("...");
>>>       throw e;
>>> } finally {
>>>      delete tmpf;
>>> }
>>> log.close();
>>>
>>> ----------------------------------
>>> Andrew.
>>>
>>>
>> This is not rhetorical, but honest: in the cases where you said "state 
>> managed
>> outside", how do you do that? i.e., how do you know for sure that the 
>> files will
>> be closed, provided that destructors are not guaranteed to be run and you 
>> can't return auto references?
> 
> "get" in getOutputFile implies that file exists somewhere and opened by 
> someone else
> so code here cannot delete it.
> 

If I understand correctly, then that someone else who opened the file would have 
to close it (or delete it, as you put it). How does the opener know when to 
close it?

> In contrary "create" in createTempFile says that it creates new instance
> so we are owning it - must delete.
> 
> If getOutputFile creates new instance then
> finally {
>      delete tmpf;
>      delete outf;
>      delete inf;
> }
> will be enough.
> 

See Walter's reply.

> In any case it shall be something one: either
> try-catch-finally or on_scope_xxx() - two similar
> and probably conflicting mechanisms is a bad design.
> 

Not necessarily. RAII and finally could be seen as "similar mechanisms", but I 
don't think having both is a bad design. How about for and foreach? do and 
while? function and delegate?

> ( This is why I like Java - with some minor exceptions
>  its grammar just perfect for the the domain it serves.
>  Ascetic but clean and simple. )
> 
> Andrew Fedoniouk.
> http://terrainformatica.com
> 
> 

-- 
Carlos Santander Bernal