Feature: Improve error messages to include the offending line in the aspect

[WhitWaldo]

I'm applying a TypeAspect to a class that looks like:

public class MyDoodad<T>
{
}

My aspect starts by assigning the type parameters to separate variables. Herein was my problem - I referenced the first and second type parameters at the top:

var typeA = builder.Target.TypeParameters[0];
var typeB = builder.Target.TypeParameters[1];

In turn, when trying to look at the Metalama preview, I received the following error:

Cannot preview the transformed code I:\...\MyObject.cs(6, 16) error LAMA0041: 'MyAspect.BuildAspect' threw 'ArgumentOutOfRangeException' when applied to 'MyObject<T>'; Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')

...and so on.

I had a lot of range accessors in my aspect so narrowing this down took a little while (lots of time staring at the wrong sections).

Yes, the issue itself is spot on, but I might suggest that instead of indicating the type the aspect is applied to as the source of the error, this should instead be enriched to indicate where in the aspect itself is the source of the error, e.g. "error LAMA0041: 'MyAspect.BuildAspect' at 'builder.Target.TypeParameters[1]' threw 'ArgumentOutOfRangeException' when applied" as this would have dramatically improved the turnaround time on identifying a fix.

Thanks for the consideration!

[PostSharpBot]

Hello @WhitWaldo, thank you for submitting this issue. We will try to get back to you as soon as possible. Note to the PostSharp team, this ticket is being tracked in our dashboard under ID TP-33099.

[gfraiteur]

Do you mean that you want to full call stack? We could give you that, but in a separate file because we cannot report exception stacks as errors -- errors and warnings must be single-lined for some reason.

[WhitWaldo]

Not necessarily the full call stack, but something slightly more "here's where the actual problem is" not "here's where A met B and caused an issue" would be useful.

To use an analogy - imagine I type up this beautiful console application and I run it. It's less useful if the error message says "MyApp.exe threw 'ArgumentOutOfRangeException' when it launched; Index was out of range" and far more useful when it breaks on or at least includes the actual line in the code that caused the issue: whatever line actually attempted to access the out-of-range index.

In the same light, it's useful to know the type of the exception, and, if applied via a fabric, potentially useful to know which type the aspect was applied to, but it'd be vastly more helpful to source specifically which statement in the aspect proved troublesome.

[gfraiteur]

Wondering if you noticed any improvements in the last releases regarding error reporting.

[gfraiteur]

I think we have improved enough on this topic. Feel free to re-open if you feel it's needed, but then be specific about the scenario to be improved.