Ok, call me insane, but I think it would be really nice to have something along these lines supported in D:

functype traced
{
    version (debug)
    {
        in {
            // writefln("Entering ", name);
        }
		
        out {
            // writefln("Exiting ", name);
        }

        except(Object x) {
            writefln("Exception caught in function ", name);
        }
    }
}


And then write:

void foo() traced
{
}


It wouldn't be that hard thing to do, although the parsing rules for functions would have to be altered to support the additional type specifier. The in and out blocks could actually be added to the function's in and out blocks and if any except block was defined in the functype, the function could be wrapped in a try block and then the exceptions could be handled.
name would be replaced by the function name, in this one case, "foo".
Moreover, the functype thingie might also take some optional parameters.

Probably not a 1.0 thing though ;) but I can see no other way to have nice traces of where an error has occured (unless we get nice stack traces) and this could prove to be useful after all. If I don't get a similar feature or stack traces that can nicely print a function call tree, I'm writing a preprocessor for D. There are so many cool things that can be done with it that sometimes the lack of a preprocessor in D is a real hit...

actually it would be better to follow the class way:

void foo() : traced
{
}

that way, there could be a list of functype's, like

void foo() : traced, logged("myLog.txt")
{
}

On Sat, 31 Jul 2004 02:00:26 +0200, h3r3tic wrote:

> Ok, call me insane, but I think it would be really nice to have something along these lines supported in D:
> 
> functype traced
> {
>      version (debug)
>      {
>          in {
>              // writefln("Entering ", name);
>          }
> 
>          out {
>              // writefln("Exiting ", name);
>          }
> 
>          except(Object x) {
>              writefln("Exception caught in function ", name);
>          }
>      }
> }
> 
> 
> And then write:
> 
> void foo() traced
> {
> }

An IDE for D could easely add and remove the print outs and/or the in and out blocks.

Ant

my editor for D:
http://leds.sourceforge.net

> An IDE for D could easely add and remove the print outs and/or
> the in and out blocks.

Yeah, I know, but the code gets very clumsy really fast. It's again about hiding the implementation, so I can just say:

void foo() : traced
{
...
}

instead e.g.

void foo()
{
    debug {
        auto CallTrace trace__ = new CallTrace("foo");
    }

   ...
}

I think the first one is more eye-friendly

"h3r3tic" <h3r3tic@dev.null> wrote in message news:ceeufl$e8n$1@digitaldaemon.com...
> Probably not a 1.0 thing though ;) but I can see no other way to have nice traces of where an error has occured (unless we get nice stack traces) and this could prove to be useful after all. If I don't get a similar feature or stack traces that can nicely print a function call tree, I'm writing a preprocessor for D. There are so many cool things that can be done with it that sometimes the lack of a preprocessor in D is a real hit...

It's no problem at all. Write an auto class:

auto class Tracer
{
    char[] name;
    this(char[] name) { this.name = name; fwriteln("entry ", name); }
    ~this() { fwriteln("exit ", name); }
}

And use it like:

void foo()
{    Tracer T = new Tracer("foo");
    ...
}

You can add some complexity to it to track the stack frames. Or, you can compile with -gt and look at how the trace code figures it out. www.digitalmars.com/ctg/trace.html

ok, let me try your approach for a second... is there a function in D which checks if an exception has been thrown ? like the uncaught_exception() in c++ ?

In article <ceeufl$e8n$1@digitaldaemon.com>, h3r3tic says...
>
>Ok, call me insane, but I think it would be really nice to have something along these lines supported in D:
>
>functype traced
>{
>     version (debug)
>     {
>         in {
>             // writefln("Entering ", name);
>         }
>
>         out {
>             // writefln("Exiting ", name);
>         }
>
>         except(Object x) {
>             writefln("Exception caught in function ", name);
>         }
>     }
>}
>
>
>And then write:
>
>void foo() traced
>{
>}

Actually just allowing "super()" outside of the constructor would probably be all that's needed to get this to work inside classes.

Its still an interesting idea, but wouldn't this work better if it were treated like class inheritance?

void baseFunction()
in{ writefln("base in"); }
body{ writefln("base body"); }
out{ writefln("base out"); }

// concreteFunction "inherits" baseMethod
void concreteFunction(): baseFunction
in{ writefln("concrete in"); }
body{ super(); writefln("concrete body"); }
out{ writefln("concrete out"); }

// test
void main(){
concreteFunction();
}

Which would generate the output:

base in
concrete in
base body (via opional call to super())
concrete body
base out
concrete out

It'd be interesting to see what someone could do if this syntax were allowed to "rewire" a class' v-table by specifying overrides on a method-by-method basis. (I'd imagine the result to be a gross perversion of D's method inheritance rules)

I'd also reckon that Typeinfo would have to go through some contortions to allow a method's inheritance to be discovered.

Is D's stack tracing code (+gt) in phobos at all, or is this done inside the compiler only?   If phobos could also contain an implicit base method/function much like Object is for classes, that utilizes this mechanism, could that feature be more easily maintained?

- Pragma

pragma <EricAnderton at yahoo dot com> wrote:
> Its still an interesting idea, but wouldn't this work better if it were treated
> like class inheritance?
> 
> void baseFunction()
> in{ writefln("base in"); }
> body{ writefln("base body"); }
> out{ writefln("base out"); }
> 
> // concreteFunction "inherits" baseMethod
> void concreteFunction(): baseFunction
> in{ writefln("concrete in"); }
> body{ super(); writefln("concrete body"); }
> out{ writefln("concrete out"); }
> 
> // test
> void main(){
> concreteFunction();
> }
> 
> Which would generate the output:
> 
> base in
> concrete in
> base body (via opional call to super())
> concrete body
> base out
> concrete out

Yeah, it's even better. Though I'd add a new available block type to the design by contract thingie for functions, so that one could do:

void foo()
in   { ... }
out  { ... }
body { ... }
catch(...) {...}

on the whole function level so that exception handling could be inherited as well.

Let me now write some hypothetical "D with function inheritance code"


void guarded()
body
{
}
catch(Exception err)
{
    writefln("Exception caught in func ", thisfunc.name);
    throw;
}

void foo() : guarded
{
    bar();
}

void bar() : guarded
{
    throw Exception("FUBAR");
}

void main()
{
    try
    {
        foo();
    } catch(Exception err)
    {
        writefln(err);  // here typeinfos are repaired so I don't have to type err.toString()   ;)
    }
}

Which would produce:

Exception caught in func bar
Exception caught in func foo
Exception                <- or whatever Exception.toString() produces


Hmmmmmm... wouldn't function inheritance be the great one feature that other languages don't have ? How to do it ? I'm not a compiler writer buy in my opinion, Python's approach is nice:

def foo():
    some code

the def statement just creates a new object whose opCall is set to execute the code given. This could work more or less the same in D.

Any oppinions/comments/flames/bitchslaps ?

> Hmmmmmm... wouldn't function inheritance be the great one feature that other languages don't have ?


Damn. Note to self: first think, then think, then think a lil bit more, ONLY then post here...

This couldn't be a killer feature. There isn't too much to inherit but the DbC blocks (+ the proposed throw block) so it would rather be an extension to the DbC, not a killer... sorry ;)

This idea is close to the 'aspect oriented programming' idea, or rather with a little extending could be used for aspect oriented programming.

The idea behind aspect oriented programming is that you take an aspect like logging or locking or .., write it once, and apply it to specified methods of a class.

Example:

aspect LockingAspect {
  void onEnter() {
    ..lock...
  }
  void onLeave() {
    ..unlock..
  }
}

class Foo {
  void fooBar() : LockingAspect {
  }
}

so onEnter is called when fooBar is called, and onLeave is called when it returns (and when an exception is throw).

The above is an idea of the syntax that could be used. In addition I am no expert on aspect oriented programming and what I have said above is off the top of my head.

As you have discovered it's impossible to implement without a preprocessor (or compiler support)

Regan

On Sat, 31 Jul 2004 02:00:26 +0200, h3r3tic <h3r3tic@dev.null> wrote:
> Ok, call me insane, but I think it would be really nice to have something along these lines supported in D:
>
> functype traced
> {
>      version (debug)
>      {
>          in {
>              // writefln("Entering ", name);
>          }
> 		
>          out {
>              // writefln("Exiting ", name);
>          }
>
>          except(Object x) {
>              writefln("Exception caught in function ", name);
>          }
>      }
> }
>
>
> And then write:
>
> void foo() traced
> {
> }
>
>
> It wouldn't be that hard thing to do, although the parsing rules for functions would have to be altered to support the additional type specifier. The in and out blocks could actually be added to the function's in and out blocks and if any except block was defined in the functype, the function could be wrapped in a try block and then the exceptions could be handled.
> name would be replaced by the function name, in this one case, "foo".
> Moreover, the functype thingie might also take some optional parameters.
>
> Probably not a 1.0 thing though ;) but I can see no other way to have nice traces of where an error has occured (unless we get nice stack traces) and this could prove to be useful after all. If I don't get a similar feature or stack traces that can nicely print a function call tree, I'm writing a preprocessor for D. There are so many cool things that can be done with it that sometimes the lack of a preprocessor in D is a real hit...



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/