1. Should crash be the top of ex.err?
- Posted by dcuny Jan 25, 2015
- 1690 views
One thing I've noticed is that calling crash() causes crash() to be at the head of the ex.err file.
While I understand why this is the case, I suggest that the error should be associated with where the error was thrown, not with the crash() routine.
Although it's technically part of the stack trace, it's not really part of the crash at all.
The exception (of course) is if there is an actual error in crash().
From my lazy developer's perspective, instead of:
C:\Euphoria\include\std\error.e:50 in procedure crash()
Unable to find parameter in queue pitch for position 50400
fmt = {85'U',110'n',97'a',98'b',108'l',101'e',32' ',116't',111'o',32' ',
102'f',105'i',110'n',100'd',32' ',112'p',97'a',114'r',97'a',109'm',101'e',
116't',101'e',114'r',32' ',105'i',110'n',32' ',113'q',117'u',101'e',117'u',
101'e',32' ',37'%',115's',32' ',102'f',111'o',114'r',32' ',112'p',111'o',
115's',105'i',116't',105'i',111'o',110'n',32' ',37'%',100'd'}
data = {
{112'p',105'i',116't',99'c',104'h'},
50400
}
msg = {85'U',110'n',97'a',98'b',108'l',101'e',32' ',116't',111'o',32' ',
102'f',105'i',110'n',100'd',32' ',112'p',97'a',114'r',97'a',109'm',101'e',
116't',101'e',114'r',32' ',105'i',110'n',32' ',113'q',117'u',101'e',117'u',
101'e',32' ',112'p',105'i',116't',99'c',104'h',32' ',102'f',111'o',114'r',
32' ',112'p',111'o',115's',105'i',116't',105'i',111'o',110'n',32' ',53'5',
48'0',52'4',48'0',48'0'}
... called from [MY_PATH]\parameter_queue.e:77 in function get_value()
this = {
{112'p',105'i',116't',99'c',104'h'},
{
{0,1259,0,110'n',7,1259,0},
{1260,5039,110'n',110'n',1,3779,0},
{5040,6299,110'n',110'n',7,1259,0},
{6300,10079,110'n',110'n',1,3779,0},
{10080,11339,110'n',110'n',7,1259,0},
{11340,15119,110'n',110'n',1,3779,0},
{15120,16379,110'n',110'n',7,1259,0},
...
I really just want to see something more like:
crash() called from [MY_PATH]\parameter_queue.e:77 in function get_value()
Unable to find parameter in queue pitch for position 50400
this = {
{112'p',105'i',116't',99'c',104'h'},
{
{0,1259,0,110'n',7,1259,0},
{1260,5039,110'n',110'n',1,3779,0},
{5040,6299,110'n',110'n',7,1259,0},
{6300,10079,110'n',110'n',1,3779,0},
{10080,11339,110'n',110'n',7,1259,0},
{11340,15119,110'n',110'n',1,3779,0},
{15120,16379,110'n',110'n',7,1259,0},
...
This will be helpful not just for me, but for the editor (like wee) which is trying to point me to an error, but instead ends pointing to the wrong thing through no fault of its own.
- David
2. Re: Should crash be the top of ex.err?
- Posted by petelomax Jan 25, 2015
- 1689 views
In Phix I solved this issue by having "without debug" in builtin files and omitting them from the ex.err. In my case it was printf() that sorely needed this. Symbol table entries have a K_wdb bit setting on them to facilitate this. As it happens, I am currently working on getting the diagnostics all working properly again, and maybe nearly half way through.
Pete
3. Re: Should crash be the top of ex.err?
- Posted by SDPringle Jan 25, 2015
- 1699 views
Sometimes the fault might be up several levels of the stack trace anyway. To me, you ought to have a list of 'called from' lines that the user can click on. This way the user gets the opportunity to jump to where he needs to go.
4. Re: Should crash be the top of ex.err?
- Posted by dcuny Jan 26, 2015
- 1663 views
Sometimes the fault might be up several levels of the stack trace anyway.
Could you give me an example of this? Maybe I'm misunderstanding you, but I can't imagine any case where I'd care to see crash() at the top level unless there actually was and error in crash().
To me, you ought to have a list of 'called from' lines that the user can click on. This way the user gets the opportunity to jump to where he needs to go.
That's pretty cool functionality. Maybe you'd have to talk to Pete about that.
In the mean time, I'd settle for Euphoria presenting a stack trace that associates the error with where I said it was, not one that associates it with the location of the crash() routine.
All the current behavior does is reveal the man behind the curtain. Since the goal of using crash() is to indicate an error at a particular spot, I'd like Euphoria to honor that request.
- David
5. Re: Should crash be the top of ex.err?
- Posted by ghaberek (admin) Jan 26, 2015
- 1630 views
In Phix I solved this issue by having "without debug" in builtin files and omitting them from the ex.err.
I really like this idea. I really dislike that some of my ex.err files are filled with so much extra data and it would be nice to distill it down.
Should I submit a feature request ticket?
-Greg
6. Re: Should crash be the top of ex.err?
- Posted by SDPringle Jan 26, 2015
- 1658 views
Suppose we make Euphoria have a special exception to crash and someone doesn't like crash or he creates his own die routine. Now, we are back where we started. So, we would be adding exceptions willy nilly here until someone says hey why don't we put some kind of #pragma in the language for routines that are like crash. This is why I would be against this kind of thing.
7. Re: Should crash be the top of ex.err?
- Posted by dcuny Jan 26, 2015
- 1644 views
Suppose we make Euphoria have a special exception to crash and someone doesn't like crash or he creates his own die routine. Now, we are back where we started. So, we would be adding exceptions willy nilly here until someone says hey why don't we put some kind of #pragma in the language for routines that are like crash. This is why I would be against this kind of thing.
That would depend on how you implement the solution, wouldn't it?
I haven't proposed a solution, I've only suggested that the behavior is wrong.
Currently, crash() isn't a reliable way to report where an error happened, because the output is completely indistinguishable from an error in crash().
Before arguing that something shouldn't be fixed because doing so is difficult, can we first agree that the behavior is wrong?
- David
8. Re: Should crash be the top of ex.err?
- Posted by jimcbrown (admin) Jan 26, 2015
- 1635 views
Suppose we make Euphoria have a special exception to crash and someone doesn't like crash or he creates his own die routine.
Not sure why someone would do that....
Now, we are back where we started. So, we would be adding exceptions willy nilly here until someone says hey why don't we put some kind of #pragma in the language for routines that are like crash.
Actually, this sounds like a great idea to me! We could use without statements to handle this sort of thing.
This is why I would be against this kind of thing.
But, why?
That would depend on how you implement the solution, wouldn't it?
I haven't proposed a solution, I've only suggested that the behavior is wrong.
Currently, crash() isn't a reliable way to report where an error happened, because the output is completely indistinguishable from an error in crash().
This is because crash() is implemented as a machine proc instead of a builtin. If one calls M_CRASH (67) directly with machine_proc(), this issue does not arise.
The simplest solution is just to make crash() a builtin. We already have precedence for doing so, e.g. platform() and M_PLATFORM (53).
Before arguing that something shouldn't be fixed because doing so is difficult, can we first agree that the behavior is wrong?
Probably. Of course, I think it's an easy fix, but YMMV.
9. Re: Should crash be the top of ex.err?
- Posted by SDPringle Jan 26, 2015
- 1645 views
This is why I would be against this kind of thing.
But, why?
Pragmas add complexity to the language.
10. Re: Should crash be the top of ex.err?
- Posted by PeteE Jan 26, 2015
- 1640 views
Sometimes the fault might be up several levels of the stack trace anyway. To me, you ought to have a list of 'called from' lines that the user can click on. This way the user gets the opportunity to jump to where he needs to go.
I like this solution the best. I've been thinking about revamping the ex.err dialog in the Wee Editor anyway, so putting the call stack in a list box would be a neat thing to have. The dialog would also give the option to open the ex.err file directly.
11. Re: Should crash be the top of ex.err?
- Posted by dcuny Jan 26, 2015
- 1608 views
Another option would be to place the error message that crash() at the head of the stack trace, like so:
crash() generated an exception in [MY_PATH]\parameter_queue.e:77 in function get_value()
Unable to find parameter in queue pitch for position 50400
C:\Euphoria\include\std\error.e:50 in procedure crash()
Unable to find parameter in queue pitch for position 50400
fmt = {...}
data = {...}
msg = {...}
... called from [MY_PATH]\parameter_queue.e:77 in function get_value()
{15120,16379,110'n',110'n',7,1259,0},
...
The stack trace is still complete, but it's clear where the exception was called from.
- David
12. Re: Should crash be the top of ex.err?
- Posted by dcuny Feb 02, 2015
- 1564 views
Bump
So are there any objections to the crash() message be placed at the top of the list without altering the stack trace, as in my prior suggestion?
If not, how do I go about making a formal request? Do I nag a developer, or code a patch for the Euphoria interpreter and parser?
Not that I want to do that, but If I do, what is the submittable and approval process?
- David
13. Re: Should crash be the top of ex.err?
- Posted by jimcbrown (admin) Feb 03, 2015
- 1560 views
Bump
So are there any objections to the crash() message be placed at the top of the list without altering the stack trace, as in my prior suggestion?
Don't think so. That said, my preference is for crash() just to be a built-in, but the first patch in wins I guess.
If not, how do I go about making a formal request?
You file a feature request ticket. (If it's accidently filed as a bug ticket BTW, that's no big deal, we can give it the correct status later.)
Do I nag a developer,
That's the second best method to get your change implemented!
or code a patch for the Euphoria interpreter and parser?
And here's the best.
Not that I want to do that, but If I do, what is the submittable and approval process?
We don't really have a process AFAIK - just someone posts the patch on the forum, asks a specific developer to look at it, and then that developer commits it. Look at the recent text.e fixes for an example...
14. Re: Should crash be the top of ex.err?
- Posted by dcuny Feb 03, 2015
- 1569 views
That said, my preference is for crash() just to be a built-in, but the first patch in wins I guess.
I'd also prefer it to be a built-in. I guess I'll hold off on the request for a bit... If WEE can cleverly figure out false positives from crash(), I won't care as much.
Thanks for the details!
- David
15. Re: Should crash be the top of ex.err?
- Posted by mattlewis (admin) Feb 03, 2015
- 1534 views
Bump
So are there any objections to the crash() message be placed at the top of the list without altering the stack trace, as in my prior suggestion?
Here's a workaround for you: Use error:crash() instead of just crash(). For reasons (it's been a while, so I don't recall, exactly) the first gets inlined while the second doesn't. So the inlined version doesn't have crash() in the stack trace.
This is probably a bad thing, as it confuses error reporting on inlined routines, but I'm not sure if there's an easy / good way to keep inlined stuff in stack traces. They should, of course, be pretty small, so there's not a whole lot of places for an error to hide, but it can be misleading.
Matt
16. Re: Should crash be the top of ex.err?
- Posted by dcuny Feb 03, 2015
- 1512 views
Here's a workaround for you: Use error:crash() instead of just crash().
Cool, thanks! 
- David
