On Thu, 01 Apr 2004 14:57:34 +1000, "Derek Parnell" <Derek.Parnell@psyc.ward> wrote:
> On Thu, 1 Apr 2004 03:39:44 +0000 (UTC) (01/Apr/04 01:39:44 PM)
> , kinghajj <kinghajj_member@pathlink.com> wrote:
> 
> > Can somebody please post some good that shows how it is used? I don't
> > understand
> > it.
> >
> >
> 
> I know what you mean. It was not until I saw some examples that the D documentation started to make any sense. The general format is ...
> 
>    try { <some statement(s) }
>    catch (<errorclass>) { <do something about it> }
>    finally { <always run> };
> 

How does that differ from:

    try { <some statement(s) }
    catch (<errorclass>) { <do something about it> }
    <always run>};

K Bochert

Karl Bochert <kbochert@copper.net> wrote:

> Perl programmers say the same thing about all manner of obfuscatory features :-)

Programming in Perl is like talking to a Wall.

:-)

-- 
dave

"Dave Sieber" <dsieber@spamnot.sbcglobal.net> wrote in message news:Xns94BE8FB6EDCA5dsiebersbc@63.105.9.61...
> Karl Bochert <kbochert@copper.net> wrote:
>
> > Perl programmers say the same thing about all manner of obfuscatory features :-)
>
> Programming in Perl is like talking to a Wall.
>
> :-)
>
> --
> dave

LOL




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.644 / Virus Database: 412 - Release Date: 3/26/2004

Karl Bochert <kbochert@copper.net> wrote:

> If those two are identical, then following the throw, the finally gets
> executed and then the catches get checked.  I'm uncomfortable with
> 'out-of-order' flow control like that.
>  So instead:
>     try{ <whatever> }
>      catch(myerr) { <common cleanup> }
>      catch(ioerr) { <ioCleanup>}
>      catch(myerr) { <myCleanup>}
>      catch(assertErr) { <assertCleanup>}
> 
> Though again,  I would refactor first.

I use exceptions a lot, and I rarely write code such as the above. The idea is that your objects should be designed to clean up after themselves, especially in the presense of exceptions. So explicit exception handlers such as above should be few and small. When there is an action that must be followed by some sort of "clean up" action, such as the closing of a file after it has been opened, you need a File object that, in its destructor, ensures that the file is closed. That way, in the case of an exception, the file is automatically "cleaned up", without endless catches to handle all of those special cases.

Same in the case of something simple: I have some logging routines that do indentation. I don't just increment the indent, log some statements, and then decrement the indent, because exceptions could cause that to fail (and then, thereafter in the log file all of the indentation is screwed up). I created an AutoIndent class, which has a reference to the Indent object it controls. In the AutoIndent constructor, the Indent object is incremented. In the destructor it is decremented. And it never screws up -- I have NO worries about exceptions in my code, and as I said above, the explicit handlers are few and small. This is what is meant by deterministic destruction, and it is also called RAII (Resource Acquisition Is Initialization). It has many more uses than just handling memory or closing files. C++ has it, Java doesn't, C# has a half-way implementation with 'Using', which works as long as you always remember to enclose statements that use objects which must be "cleaned up" in a 'Using' statement, and write a Dispose() method for your classes.

And the good news is that D has it, implemented with the 'auto' keyword on a class. Even better: if you don't want to hassle with writing another class for something simple, you use 'finally', which is what Java and C# have. That's what it's for in D, and that's the only time you should use it: when you do NOT have a class that automatically handles its own cleanup, and you want to make sure that resources are handled in the presence of an exception.  Walter's approach with D is a combination of the workability of both Java and C++.  C++ programmers often complain about the lack of 'finally', because writing totally safe exception handling code requires a unique class for each kind of object, such as my AutoIndent example -- which was fine with me in that case, because I use AutoIndent all over the place, and I know it's always correct. If I hadn't written that class, I'd instead have had to write 'finally' everywhere, except that C++ doesn't have it :-(


-- 
dave

On Fri, 2 Apr 2004 16:40:23 +0000 (UTC), Dave Sieber <dsieber@spamnot.sbcglobal.net> wrote:

> I use exceptions a lot, and I rarely write code such as the above. The idea is that your objects should be designed to clean up after themselves, especially in the presense of exceptions. So explicit exception handlers such as above should be few and small. When there is an action that must be followed by some sort of "clean up" action, such as the closing of a file after it has been opened, you need a File object that, in its destructor, ensures that the file is closed. That way, in the case of an exception, the file is automatically "cleaned up", without endless catches to handle all of those special cases.
> 
>  <clipped>

> And the good news is that D has it, implemented with the 'auto' keyword on a class. Even better: if you don't want to hassle with writing another class for something simple, you use 'finally', which is what Java and C# have. That's what it's for in D, and that's the only time you should use it: when you do NOT have a class that automatically handles its own cleanup, and you want to make sure that resources are handled in the presence of an exception.  Walter's approach with D is a combination of the workability of both Java and C++.  C++ programmers often complain about the lack of 'finally', because writing totally safe exception handling code requires a unique class for each kind of object, such as my AutoIndent example -- which was fine with me in that case, because I use AutoIndent all over the place, and I know it's always correct. If I hadn't written that class, I'd instead have had to write 'finally' everywhere, except that C++ doesn't have it :-(
> 
> 
> -- 
> dave

1)
 I still don't know the order of execution!
     try{ <A> }
     catch {   <B>   }
     finally {  < C >  }
if A thows an error that is caught by the catch phrase, does <C> get executed before or after <B> ???

2)
I am not arguing against the functionality of try-catch-finally.
It just seems that the try clause could be eliminated in favor of the entire start of the function
(before the catch) and the finally could be eliminated in favor of the entire end
of the function.


Kark Bochert

In article <1103_1081102397@bose>, Karl Bochert says...
>
>On Fri, 2 Apr 2004 16:40:23 +0000 (UTC), Dave Sieber <dsieber@spamnot.sbcglobal.net> wrote:
>
>> I use exceptions a lot, and I rarely write code such as the above. The idea is that your objects should be designed to clean up after themselves, especially in the presense of exceptions. So explicit exception handlers such as above should be few and small. When there is an action that must be followed by some sort of "clean up" action, such as the closing of a file after it has been opened, you need a File object that, in its destructor, ensures that the file is closed. That way, in the case of an exception, the file is automatically "cleaned up", without endless catches to handle all of those special cases.
>> 
>>  <clipped>
>
>> And the good news is that D has it, implemented with the 'auto' keyword on a class. Even better: if you don't want to hassle with writing another class for something simple, you use 'finally', which is what Java and C# have. That's what it's for in D, and that's the only time you should use it: when you do NOT have a class that automatically handles its own cleanup, and you want to make sure that resources are handled in the presence of an exception.  Walter's approach with D is a combination of the workability of both Java and C++.  C++ programmers often complain about the lack of 'finally', because writing totally safe exception handling code requires a unique class for each kind of object, such as my AutoIndent example -- which was fine with me in that case, because I use AutoIndent all over the place, and I know it's always correct. If I hadn't written that class, I'd instead have had to write 'finally' everywhere, except that C++ doesn't have it :-(
>> 
>> 
>> -- 
>> dave
>
>1)
> I still don't know the order of execution!
>     try{ <A> }
>     catch {   <B>   }
>     finally {  < C >  }
>if A thows an error that is caught by the catch phrase, does <C> get executed before or after <B> ???
>

A, then B, then C, then the rest if the function.
If no error:
If the try has a return it is executed.
If not, then finally is executed.
If finally has a return it is executed.
If not, then we fall into the rest of the function.
If an error:
If the try has a return after the error point, we don't get to it.
If the catch has a return, it waits until after the finally is executed.
If the finally has a return it is executed, not the waiting catch one.
If not, the waiting catch return is executed.
If the catch has no return, the finally is executed and its return, if any, is
executed, if none, we fall into the rest of the function.

>2)
>I am not arguing against the functionality of try-catch-finally.
>It just seems that the try clause could be eliminated in favor of the entire start of the function
>(before the catch) and the finally could be eliminated in favor of the entire end
>of the function.
>
>Kark Bochert
>
Perhaps so, or you could have a function with multiple possible things to
process where you wanted to let the errors through in some cases, catch them for
others with differing cleanup actions.  Really, its coder's option whether to
enclose separate blocks with their own error handling, or have a large scope
with multiple catch blocks.
Being able to use this for debugging has interesting possibilities, but the
primary use is to protect yourself from user crap input, inexperienced future
program maintenance, unexpected language or library changes, or god forbid, the
possibility of inexact or incomplete coding on your part.

Karl Bochert <kbochert@copper.net> wrote:

> 1)
>  I still don't know the order of execution!
>      try{ <A> }
>      catch {   <B>   }
>      finally {  < C >  }
> if A thows an error that is caught by the catch phrase, does <C> get
> executed before or after <B> ???

They are executed in the order they are written there. The code in the 'catch' block might not execute if the exception it specifies is not thrown, but the 'finally' is always executed, even if everything went fine and no exception was thrown. 'finally' is optional, but every 'try' must be matched with one or more 'catch' clauses. Any 'auto' object created in that scope (from the brace after the keyword 'try' to the closing brace before 'catch') is destroyed, just as they are in any other kind of block enclosed in braces (functions, for, while, do, switch, etc.)

> I am not arguing against the functionality of try-catch-finally.
> It just seems that the try clause could be eliminated in favor of the
> entire start of the function (before the catch) and the finally could
> be eliminated in favor of the entire end of the function.

That could be one way of doing it, but I think people might object because they want to do other things in the function, before or after the try/catch. Also, keep in mind that try/catch defines a scope, and to have exact control over the lifetime of objects, you want your scopes precise. An object might not exist throughout the entire function, especially in a loop. If you are performing an action on a series of objects, each of which is created, processed, and destroyed in a loop, that loop is the scope of those objects, not the entire function. And if you wanted to catch exceptions duing the processing of those objects, and you want to continue operations even if one fails, you would want to put the try/catch inside the loop, but around the operations before performed on the objects. That way, each object's lifetime is tightly controlled, and your loop will continue on despite the failure (not uncommon -- for example, a routine to process a set of files might encounter an error on one of them, but you'd still want the rest of the files to be processed).

-- 
dave

Minor addition, see below.

In article <c4pq6i$u89$1@digitaldaemon.com>, larry cowan says...
>
>In article <1103_1081102397@bose>, Karl Bochert says...
>>
>>On Fri, 2 Apr 2004 16:40:23 +0000 (UTC), Dave Sieber <dsieber@spamnot.sbcglobal.net> wrote:
>>
>>> I use exceptions a lot, and I rarely write code such as the above. The idea is that your objects should be designed to clean up after themselves, especially in the presense of exceptions. So explicit exception handlers such as above should be few and small. When there is an action that must be followed by some sort of "clean up" action, such as the closing of a file after it has been opened, you need a File object that, in its destructor, ensures that the file is closed. That way, in the case of an exception, the file is automatically "cleaned up", without endless catches to handle all of those special cases.
>>> 
>>>  <clipped>
>>
>>> And the good news is that D has it, implemented with the 'auto' keyword on a class. Even better: if you don't want to hassle with writing another class for something simple, you use 'finally', which is what Java and C# have. That's what it's for in D, and that's the only time you should use it: when you do NOT have a class that automatically handles its own cleanup, and you want to make sure that resources are handled in the presence of an exception.  Walter's approach with D is a combination of the workability of both Java and C++.  C++ programmers often complain about the lack of 'finally', because writing totally safe exception handling code requires a unique class for each kind of object, such as my AutoIndent example -- which was fine with me in that case, because I use AutoIndent all over the place, and I know it's always correct. If I hadn't written that class, I'd instead have had to write 'finally' everywhere, except that C++ doesn't have it :-(
>>> 
>>> 
>>> -- 
>>> dave
>>
>>1)
>> I still don't know the order of execution!
>>     try{ <A> }
>>     catch {   <B>   }
>>     finally {  < C >  }
>>if A thows an error that is caught by the catch phrase, does <C> get executed before or after <B> ???
>>
>
>A, then B, then C, then the rest of the function.
>If no error:
>If the try has a return it is executed.
>If not, then finally is executed.
>If finally has a return it is executed.
>If not, then we fall into the rest of the function.
>If an error:
>If the try has a return after the error point, we don't get to it.
>If the catch has a return, it waits until after the finally is executed.
>If the finally has a return it is executed, not the waiting catch one.
>If not, the waiting catch return is executed.
>If the catch has no return, the finally is executed and its return, if any, is
>executed, if none, we fall into the rest of the function.
>
Oh, and if no error, and a finally with no return, a try return will wait until after the finally is executed, then return.  (Finally is always executed if it exists.)
>
>>2)
>>I am not arguing against the functionality of try-catch-finally.
>>It just seems that the try clause could be eliminated in favor of the entire start of the function
>>(before the catch) and the finally could be eliminated in favor of the entire end
>>of the function.
>>
>>Kark Bochert
>>
>Perhaps so, or you could have a function with multiple possible things to
>process where you wanted to let the errors through in some cases, catch them for
>others with differing cleanup actions.  Really, its coder's option whether to
>enclose separate blocks with their own error handling, or have a large scope
>with multiple catch blocks.
>Being able to use this for debugging has interesting possibilities, but the
>primary use is to protect yourself from user crap input, inexperienced future
>program maintenance, unexpected language or library changes, or god forbid, the
>possibility of inexact or incomplete coding on your part.
>
>

Karl Bochert wrote:


> I am not arguing against the functionality of try-catch-finally.
> It just seems that the try clause could be eliminated in favor of the entire start of the function
> (before the catch) and the finally could be eliminated in favor of the entire end
> of the function.

The idea behind 'finally' is that it will execute *no matter what*. This is very useful for cleaning up external resources. (incomplete SQL transactions, open file handles, and so forth)

If an exception is thrown someplace and a function does not terminate normally, finally is offers an elegant way to make sure things are cleaned up, lest programs be stuck with very subtle resource leaking bugs.

 -- andy

 1)
>  I still don't know the order of execution!
>      try{ <A> }
>      catch {   <B>   }
>      finally {  < C >  }
> if A thows an error that is caught by the catch phrase, does <C> get
executed before or after <B> ???
>

Just put printf's in each block and you will see the  order.

> 2)
> I am not arguing against the functionality of try-catch-finally.
> It just seems that the try clause could be eliminated in favor of the
entire start of the function
> (before the catch) and the finally could be eliminated in favor of the
entire end
> of the function.
>

But wouldnt that make the exception much harder to track?  You would have no control over the amount of statements that you were "try"ing to catch the exception from.

Phill.

> Kark Bochert
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004