develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Broken stack traces from use statements.

Thread Previous | Thread Next
From:
Ovid via perl5-porters
Date:
January 14, 2022 15:59
Subject:
Re: Broken stack traces from use statements.
Message ID:
1534407074.138544.1642175941641@mail.yahoo.com
On Friday, 14 January 2022, 15:54:27 CET, Leon Timmermans <fawaka@gmail.com> wrote:

> > But those assumptions are basically broken, so I'm not sure your point. Classic case of GIGO.
>
> It's not broken if it gets the job done, is it?

> I agree with you that the new behavior is far more usable than the older behavior, but that doesn't
> mean people haven't put the old behavior to use.

I think the old behavior kind of worked because generally, stack traces work. It appears to be the use/require case which is problematic.

However, in the use/require case, if the apparently pseudo-random ordering is deterministic, on my machine the first stack frame grabbed happens to be correct. If that holds (pretty sure it must), then for the 'import' case where you're trying to figure out where you're exporting to, you're going to export those functions to the right spot. It's when you hit stack traces that it becomes an unusable mess.

As it stands:

* The stack trace is clearly incorrect
* That makes it useless for debugging
* When you're working on a *huge* system and get those traces, it's miserable

Given that, I suspect the most useful discussions are about *how* to fix it and/or *when* to fix it..

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 


Buy my book! - http://bit.ly/beginning_perl


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About