in reply to Why isn't a fatal error trappable?
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Why isn't a fatal error trappable?
by perl-diddler (Chaplain) on Nov 16, 2010 at 12:23 UTC | |
The error and contextual lines I'll put here, but if you want the full thing, I've no problems posting it...(terror though it may be!) The error happens on the 2nd run (cuz it only fetches 1 page at a time at this point). So showing the 1st and 2nd runs: The code is in my "dumpfromstart" routine that's called during a program "fault" ... so the program is in the process of dying from an error already, ...OH FRACK... I just found it...BUT, I still am not sure why it's dying with a readonly-only error there. I was staring at the place where I got the 2nd error (+ the 'partial string' routine): But the problem was before it ever got here in the actual error catch routine where I disabled the error handler before it ever called dumpfromstart: Sigh.... It still doesn't really tell me why it's dying from a read-only assignment there, since the place where it's dying should be "on the stack" -- OR possibly undefined -- but if it was undefined, it wouldn't /shouldn't the assignment "auto-vivify" the undef? I'm not sure how that statement would ever die from an assignment to a readonly var... Maybe "alias" creates a condition where auto-vivify doesn't happen? ...hmmmm P.S. -- you can see the start of the bit of the other problem I mentioned right after this one (chronologically).... I.e. utf8 routines are complaining about binary output not looking right... | [reply] [d/l] [select] |
by roboticus (Chancellor) on Nov 16, 2010 at 13:11 UTC | |
| [reply] [d/l] | |
by ikegami (Patriarch) on Nov 16, 2010 at 15:29 UTC | |
No, a minimal runnable demonstration of the problem. | [reply] |