• Amex (23/23) Jun 02 2019 When my app crashes almost always it breaks in to some random
• Rainer Schuetze (7/37) Jun 03 2019 I guess you are seeing these files because you are building the "private
• Amex (3/46) Jun 04 2019 I disabled private phobos and had just my code... it just broke

Amex <Amex gmail.com> writes:

When my app crashes almost always it breaks in to some random 
internal D file rather than my code.

This does two things:

1. I have to use the stack to locate my code that caused the 
exception
2. It opens up the file and then sticks it in the bin and it 
usually ends up staying there and gets in the way.

I have no need to see such files.

I have a suggestion that should be easy to solve this:

1. Allow one to add filenames to a list of files to avoid 
breaking in to them(they are not opened up except in rare cases). 
e.g., exception.d
2. Allow one to ignore files not inside the project.
3. Use the stack and only go to the line that makes sense with 
these rules. E.g., don't go to the deepest line that is pointing 
to files in 1 or 2.

Any or all these could be used(optionally) to solve the problem 
in 99% of the cases.

This makes getting to the error more direct since it's not due to 
the code that the debugger is breaking in to(such as exception.d) 
but user code.

One can always follow the stack trace to go deeper if they want 
to further see.

Rainer Schuetze <r.sagitario gmx.de> writes:

On 02/06/2019 21:37, Amex wrote:
 When my app crashes almost always it breaks in to some random internal D
 file rather than my code.
 
 This does two things:
 
 1. I have to use the stack to locate my code that caused the exception
 2. It opens up the file and then sticks it in the bin and it usually
 ends up staying there and gets in the way.
 
 I have no need to see such files.
 
 I have a suggestion that should be easy to solve this:
 
 1. Allow one to add filenames to a list of files to avoid breaking in to
 them(they are not opened up except in rare cases). e.g., exception.d
 2. Allow one to ignore files not inside the project.
 3. Use the stack and only go to the line that makes sense with these
 rules. E.g., don't go to the deepest line that is pointing to files in 1
 or 2.
 
 Any or all these could be used(optionally) to solve the problem in 99%
 of the cases.
 
 This makes getting to the error more direct since it's not due to the
 code that the debugger is breaking in to(such as exception.d) but user
 code.
 
 One can always follow the stack trace to go deeper if they want to
 further see.
 

I guess you are seeing these files because you are building the "private
phobos" library, too, i.e. you are explicitly asking for being able to
debug phobos.

If you disable that, you'll only see template instances generated by
your modules in the debugger. With the debugger option "Enable just my
code" you might also shrink the callstack.

Amex <Amex gmail.com> writes:

On Monday, 3 June 2019 at 18:07:07 UTC, Rainer Schuetze wrote:
 On 02/06/2019 21:37, Amex wrote:
 When my app crashes almost always it breaks in to some random 
 internal D file rather than my code.
 
 This does two things:
 
 1. I have to use the stack to locate my code that caused the 
 exception 2. It opens up the file and then sticks it in the 
 bin and it usually ends up staying there and gets in the way.
 
 I have no need to see such files.
 
 I have a suggestion that should be easy to solve this:
 
 1. Allow one to add filenames to a list of files to avoid 
 breaking in to
 them(they are not opened up except in rare cases). e.g., 
 exception.d
 2. Allow one to ignore files not inside the project.
 3. Use the stack and only go to the line that makes sense with 
 these
 rules. E.g., don't go to the deepest line that is pointing to 
 files in 1
 or 2.
 
 Any or all these could be used(optionally) to solve the 
 problem in 99%
 of the cases.
 
 This makes getting to the error more direct since it's not due 
 to the code that the debugger is breaking in to(such as 
 exception.d) but user code.
 
 One can always follow the stack trace to go deeper if they 
 want to further see.
 

 I guess you are seeing these files because you are building the 
 "private phobos" library, too, i.e. you are explicitly asking 
 for being able to debug phobos.

 If you disable that, you'll only see template instances 
 generated by your modules in the debugger. With the debugger 
 option "Enable just my code" you might also shrink the 
 callstack.

I disabled private phobos and had just my code... it just broke 
in to variant.d.