Thread overview
Visual D ignore files during exception
Jun 02, 2019
Amex
Jun 03, 2019
Rainer Schuetze
Jun 05, 2019
Amex
June 02, 2019
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.



June 03, 2019

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.

June 05, 2019
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.