View mode: basic / threaded / horizontal-split · Log in · Help
May 03, 2005
Re: Stack Tracing
"John Demme" <me@teqdruid.com> wrote in message 
news:1115152504.21959.6.camel@localhost.localdomain...
> On Tue, 2005-05-03 at 13:45 -0400, Ben Hinkle wrote:
>> "Maxime Larose" <mlarose@broadsoft.com> wrote in message
>> news:d58c31$2mal$1@digitaldaemon.com...
>> >
> ...
>> If a goal of the stack-trace feature is to dump stacks without throwing 
>> then
>> why make it necessary to instantiate an exception? I'm thinking of an API
>> like Java's Thread.dumpStack which dumps the stack of the code calling
>> dumpStack. I think in the case of a thrown exception the stack should be 
>> at
>> the throw since that is where the "error" truely happens and that's where 
>> a
>> programmer would start debugging the issue.
> I disagree, as I've done things like this in Java:
> try {
> someMethod();
> } catch (MyException e) {
> //Examine exception more closely
> if (ICanHandle(e)) {
> handle(e);
> } else {
> throw e;
> }
> }
>
> Now given, this is really just a work around for an extremely poor
> Exception hierarchy, but I think it shows that the error doesn't
> necessarily occur at the throw.  I'd say a stack trace should be
> generated by the constructor (or not, depending on parameters) and also
> have a method .generateST() to (re-)generate the ST for maximum
> flexibility.
>
> John Demme

The stack is generated at the original throw inside someMethod. I can buy 
the argument that if you rethrow an exception it doesn't step on the stack 
that is already there. You're right that it shouldn't lose the stack from 
the original throw/ctor.
May 04, 2005
Re: Stack Tracing
> Been there, doing that ;)  Your stack trace feature will definately be in
Ares,
> whether it ends up in Phobos or not.
>

What is the design goals for Ares? I skimmed through the forum on dsource,
but couldn't find the reason for its existence...
(Sent me a RTFM with a link if I missed the obvious... ;)

Thanks
May 04, 2005
Re: Stack Tracing
In article <d5apue$27k6$1@digitaldaemon.com>, Maxime Larose says...
>
>> Been there, doing that ;)  Your stack trace feature will definately be in
>Ares,
>> whether it ends up in Phobos or not.
>>
>
>What is the design goals for Ares? I skimmed through the forum on dsource,
>but couldn't find the reason for its existence...
>(Sent me a RTFM with a link if I missed the obvious... ;)

The birth of Ares largely stemmed from a general sense of frustration regarding
Phobos submissions (namely that such things often seemed ignored or, at best,
quite delayed before inclusion).  Some thought that perhaps a group of motivated
people could ease Walter's workload (and speed the development of Phobos) by
reviewing submissions and presenting them to Walter in a more structured manner.
A driving concern was that some don't consider Phobos to be up to snuff as a
standard library, and that it would speed the langauge's development if Walter
could focus on language issues and leave others to fuss over library
development.  Perhaps as a result of this dissatisfaction with existing Phobos
components, the Ares project changed rather quickly into one aimed at creating
an entirely new standard library, complete with accompanying spec.  As this is a
relatively large project that may prove to be ultimately futile (since Walter
has veto power on all things D), interest waned and that's pretty much where we
stand now.

I've continued development of Ares in my (recently limited) spare time and the
project has garnered some renewed interest from like-minded individuals.  Going
forward, I do expect Ares development to pick up substantially.  And whether or
not it's ultimately accepted or not, I plan to use it for my own programming
projects.  Currently, Ares represents a minimal runtime library for DMD (and
soon for GDC as well).  It consists of three pieces: ares, dmdrt, and dmdgc.
The latter two portions are code extracted from Phobos--dmdrt contains all
runtime code that the DMD compiler requires, and dmdgc is the GC shipped with
phobos (a driving concern for this separation was that the GC, runtime, and
standard library should all be independent from one another and only interact in
specific, structured ways--they're somewhat intertwined in Phobos).  Some
remaining pieces still need attention--the core exception structure needs some
refactoring, and the GC interface hasn't been touched--but for the most part I
think it makes a fairly solid starting point for development.  And once these
final details have been hammered out I expect that development will accelerate
quickly.

As for the manual, there isn't one yet :)  And as code has just begun to be
checked into the SVN repository (I'd been maintaining it on my home PC until
recently) there are likely some access issues there as well.  In the meantime, I
keep an up to date copy of the Ares source on my D "website":
http://home.f4.ca/sean/d


Sean
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home