Comments/bugs

ahosie

I've been using Exception Hunter for a few weeks now, and have found it a brilliant tool to underline data validation flaws.

Love it, but a few notes/bugs that are making my life harder as a user:

*

Top of my list - right-click -> Remove Assembly removes the assembly from the list, but does not unlock the binary file. Ergo the solution cannot be compiled in VS and re-analysed in Exception Hunter without first closing Exception Hunter.
* Analysis of mscorlib methods is required every time Exception Hunter is executed. This takes a long, long time. This combined with the first note, makes for a very slow progress.
* The output stack trace is displayed in no particular order, as far as I can tell. Ordering by line number descending would be a nice option.
* The method list is ordered by member name descending. Ordering by method signature line number descending would be a nice option.
* Setting up a queue of methods to be analysed would be nice, allowing me to tick 5 modified routines, then return to a completed analysis after a coffee or two.
* As already covered in <this post>, the cancellation of analysis could be a bit more intuitive.

I mention the line number ordering as modifications are been made on-the-fly, and right-click -> Open with ... functionality is rendered useless once an early method is modified in a code file.


Regardless of the above issues, I expect I'll be using this application for many years to come.

James Moore

Hi,

Thanks for your feedback, and I am glad you like the tool!

The locking of the binary/pdb files is certainly top of our list of items to fix too. Unfortunately, from what I understand it is a limitation of one of the third party libraries we use which we will be looking to replace.

The ordering of stack traces/methods sounds like a sensible idea and something we will look into when working on the next point release.

The mscorlib analysis (and the possibility of caching it) is something we discussed at length, the reason we went for re-analysis each time is that we can give more accurate results (for example if we can determine that a variable you pass into a core library function can never be null then we can track that and know that ArgumentNullExceptions will never be thrown) this is of course a trade off with speed.

I like the idea of an analysis queue and I will talk to our designers about ways in which we could achieve this.

Have you tried out the command line version yet? Its in the program directory and called Hunt.exe - you can use it like this to analyse all methods in an assembly:

Hunt.exe /all /assembly:MyAssembly.dll [/mr:methodReport.html or /er:exceptionReport.html or /xml:output.xml] [/sd:n]

where /mr /er /xml is the output type you would like and /sd is the stack depth you would like in the xml report (/er and /mr ignore stack information). I would suggest using a fairly small argument to /sd as the xml file can get pretty large if /sd is too big.

Thanks once again!

James

ahosie

Thanks for the prompt response James.
Looking forward to the next release, and a not-to-distant (?) fix of file locking.

I am making use of the Hunt CLI and XSLT stylesheet you cooked up in <this post>. Thankyou.

ahosie

Further to my last comment, it would also be nice if the CLI hunt included a stack trace w/line numbering in the XML output.

Side question - why are all object constructor method names abbreviated to ".ctor" or ".cctor" ?