1. Should crash be the top of ex.err?

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

new topic     » topic index » view message » categorize

2. Re: Should crash be the top of ex.err?

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: Should crash be the top of ex.err?

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.

new topic     » goto parent     » topic index » view message » categorize

4. Re: Should crash be the top of ex.err?

SDPringle said...

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().

SDPringle said...

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

new topic     » goto parent     » topic index » view message » categorize

5. Re: Should crash be the top of ex.err?

petelomax said...

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

new topic     » goto parent     » topic index » view message » categorize

6. Re: Should crash be the top of ex.err?

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.

new topic     » goto parent     » topic index » view message » categorize

7. Re: Should crash be the top of ex.err?

SDPringle said...

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

new topic     » goto parent     » topic index » view message » categorize

8. Re: Should crash be the top of ex.err?

SDPringle said...

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....

SDPringle said...

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.

SDPringle said...

This is why I would be against this kind of thing.

But, why?

dcuny said...

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).

dcuny said...

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.

new topic     » goto parent     » topic index » view message » categorize

9. Re: Should crash be the top of ex.err?

jimcbrown said...
SDPringle said...

This is why I would be against this kind of thing.

But, why?

Pragmas add complexity to the language.

new topic     » goto parent     » topic index » view message » categorize

10. Re: Should crash be the top of ex.err?

SDPringle said...

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.

new topic     » goto parent     » topic index » view message » categorize

11. Re: Should crash be the top of ex.err?

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

new topic     » goto parent     » topic index » view message » categorize

12. Re: Should crash be the top of ex.err?

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

new topic     » goto parent     » topic index » view message » categorize

13. Re: Should crash be the top of ex.err?

dcuny said...

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.

dcuny said...

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.)

dcuny said...

Do I nag a developer,

That's the second best method to get your change implemented!

dcuny said...

or code a patch for the Euphoria interpreter and parser?

And here's the best.

dcuny said...

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...

new topic     » goto parent     » topic index » view message » categorize

14. Re: Should crash be the top of ex.err?

jimcbrown said...

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

new topic     » goto parent     » topic index » view message » categorize

15. Re: Should crash be the top of ex.err?

dcuny said...

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

new topic     » goto parent     » topic index » view message » categorize

16. Re: Should crash be the top of ex.err?

mattlewis said...

Here's a workaround for you: Use error:crash() instead of just crash().

Cool, thanks! smile

- David

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu