Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Exception message column hides the critical part of the contents
jnm236
#1 Posted : Monday, March 21, 2016 3:28:58 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/25/2015(UTC)
Posts: 57
Location: United States of America

Thanks: 1 times
Was thanked: 4 time(s) in 4 post(s)
This may be a more appropriate place to follow up with issues, since the UserVoice suggestion has been completed.

Unfortunately this feature is not usable yet. The message is not formatted and AggregateException is not unwrapped as I had asked. There isn't much room for the column. I want to see `Assert.AreEqual failed. Expected:<1>. Actual:<2>.` That will barely fit in the window already, but there's no way I'm going to see it when the column actually contains: `System.AggregateException: One or more errors occurred. ---> Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException: Assert.AreEqual failed. Expected:<1>. Actual:<2>.`

Currently, I only have enough room for it to show `System.AggregateException: One or more erro...`.

I am never going to want to see AggregateException. If someday it matters, the fact that the exception was wrapped in an AggregateException is something I can see from the results pane when I click on it.

For the column, please strip any wrapping AggregateExceptions and put the Message property first, followed by the short name of the type (.GetType().Name). Something like this: "{message} [{type}]".

Thank you!
Remco
#2 Posted : Monday, March 21, 2016 9:46:15 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Hi,

Thanks for the feedback on this.

Unfortunately, this is now becoming much more complicated, as NCrunch now needs to pick apart exception data to try and construct this report. There are also edge cases to consider (i.e. what about aggregate exceptions that have their own physical type descending from aggregateexception?).

This feature was implemented because simply placing an exception message into a column was very easy to do ... though what you are requesting is much more involved. Unfortunately I'll need to see more demand on the uservoice request before I can justify the effort needed to make such a change. Sorry.
jnm236
#3 Posted : Monday, March 21, 2016 10:03:34 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/25/2015(UTC)
Posts: 57
Location: United States of America

Thanks: 1 times
Was thanked: 4 time(s) in 4 post(s)
Remco;8461 wrote:
Hi,

Thanks for the feedback on this.

Unfortunately, this is now becoming much more complicated, as NCrunch now needs to pick apart exception data to try and construct this report. There are also edge cases to consider (i.e. what about aggregate exceptions that have their own physical type descending from aggregateexception?).

This feature was implemented because simply placing an exception message into a column was very easy to do ... though what you are requesting is much more involved. Unfortunately I'll need to see more demand on the uservoice request before I can justify the effort needed to make such a change. Sorry.


My plea is that I just need to be able to see expected vs actual in the column.
It wouldn't take much. This is all I would want dropped in:

Code:

string FormatShortMessage(Exception ex)
{
	if (ex.GetType() == typeof(AggregateException) && ex.InnerException != null) ex = ex.InnerException;
	return $"{ex.Message} [{ex.GetType().Name}]";
}


Please?
Remco
#4 Posted : Monday, March 21, 2016 11:53:57 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
I know it looks easy, but of course, there's always hidden bits.

Trust me. It isn't as simple as you think it is. I would need to see solid demand for such a feature to warrant implementing it.
jnm236
#5 Posted : Thursday, March 24, 2016 2:07:30 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/25/2015(UTC)
Posts: 57
Location: United States of America

Thanks: 1 times
Was thanked: 4 time(s) in 4 post(s)
Remco;8463 wrote:
I know it looks easy, but of course, there's always hidden bits.

Trust me. It isn't as simple as you think it is. I would need to see solid demand for such a feature to warrant implementing it.


What's the risk? Worst case, the column is unusable. But the column wasn't available in the first place.
Remco
#6 Posted : Thursday, March 24, 2016 10:13:38 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
jnm236;8485 wrote:

What's the risk? Worst case, the column is unusable. But the column wasn't available in the first place.


The data you're asking for isn't sitting in the UI where it can be easily obtained.

It would need to be extracted and parsed at test runtime because it relies on runtime exception objects. Which means it needs to be obtained for every test exception for every user, regardless of whether they are using the column or not.

The data needs to be piped up from the runtime environment, through the grid nodes and compressed over a network, through the engine, through the IPC barrier between the engine and the UI. There would need to be handling for edge cases such as stack traces written in different languages (i.e. German etc), or people using derived types of AggregateException ... these are the issues that on first glance I already know about, there are likely to be additional unknown unknowns.

It's not a 'big deal', but we're no longer looking at simply just adding a small piece of data to a column. To justify making these changes and carrying their weight through the lifetime of the product, I'd need to be sure there is a good number of people that would make use of the feature.
jnm236
#7 Posted : Friday, March 25, 2016 12:21:53 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/25/2015(UTC)
Posts: 57
Location: United States of America

Thanks: 1 times
Was thanked: 4 time(s) in 4 post(s)
That's a perfectly reasonable constraint. On the flip side, that information clarifies the problem at hand. Exception objects aren't strictly the domain of what we are interested anyway. The domain is text. All I need is to be able to trim the beginning so the message portion is visible.

With that in mind, please consider this:
Code:

string FormatShortMessage(string fullMessageText)
{
    const string aggregateExceptionPrefix = "System.AggregateException: One or more errors occurred. ---> ";
    if (fullMessageText.StartsWith(aggregateExceptionPrefix, StringComparison.Ordinal))
        fullMessageText = fullMessageText.Substring(aggregateExceptionPrefix.Length);
    
    const string assertFailedException = "Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException: ";
    if (fullMessageText.StartsWith(assertFailedException, StringComparison.Ordinal))
        fullMessageText = fullMessageText.Substring(assertFailedException.Length);

    return fullMessageText;
}


This is actually incredibly safe because you are matching exact text, text which you already know you don't want to see, rather than doing semantic parsing to achieve that as a byproduct.
I know your reaction might be "what about languages other than English," but there is no harm waiting until that is requested. The ability to see multiple exception messages would be huge for me.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.045 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download