2

I'm using Visual Studio 2013 Ultimate, with no chance to upgrade to Visual Studio 2015 by the moment.

I'm looking for a way to determine all the possible exceptions that a target member can throw, so researching I heard about Microsoft Pex which is an IDE extension for VS2008/VS2010 which tries to determine "all" the possible exceptions that a target member can throw:

enter image description here

I'm not sure about its logic or how it works because I cannot install it for my Visual Studio version, it comes as a MSI package that once unpacked seems it does not have a vsixmanifest file to make the known trick to let work a extension for newer Visual Studio versions.

By the way, Microsoft exposes that PEX is replaced by a feature of Visual Studio 2015 named IntelliTest

NEW: IntelliTest in Visual Studio 2015 is the evolution of Pex. IntelliTest is a feature integrated in Visual Studio Enterprise 2015. IntelliTest works together with Fakes.

However I don't think so, since PEX by the comments I heard seems a little tool with an unique purpose related to determining possible exceptions (as commented for example here), IntelliTest seems a full featured unit testing package, on which I'm not interested to, I just want to inspect for possible exceptions of a target member.

So, following my research I also found ExceptionHunter of RedGate's:

enter image description here

But it became a discontinued software on year 2010 because technically reasons after .Net framework 2.0 appeared, and RedGates does not provide any more a download url to this useful software on their website, I can't find this software.

So, today in .Net development, what a programmer can do to determine, in an automated way, "all" the possible exceptions that a target member can throw?.

Note that I'm not looking for a full unit testing features like Nunit because these kind of packages meets a lot of features that I don't need, but if a unit testing package like that offers a simple way to determine all the exceptions of a member then I'm open to suggestions.

Community
  • 1
  • 1
ElektroStudios
  • 19,105
  • 33
  • 200
  • 417
  • What do you think you gain by knowing all possible exceptions from a function call? – xxbbcc Nov 02 '15 at 19:47
  • @xxbbcc The opportunity to discover then handle potential exceptions that all we could miss at first view. Thanks for comment. – ElektroStudios Nov 02 '15 at 19:48
  • 2
    How would you use the output of such an automated routine? In what way would you use it day-to-day? The usual approach to "discover" potential exceptions is to read the API documentation for said methods - possible exceptions should be present in any half-decent API docs. – James Thorpe Nov 02 '15 at 19:49
  • 1
    @ElektroStudios I think (maybe because of the phrasing of my comment) you misunderstood the point of my question (@JamesThorpe put it better): what do you do with a random exception that you discover this way? How would you handle it any differently than without this tool? – xxbbcc Nov 02 '15 at 19:51
  • Another consideration is that the exception handling inside of a given scope should be limited to exceptions that the scope *can reasonably handle*; I'd argue that a block of code shouldn't have to know every possible exception that the methods it calls throw, just as it shouldn't have to understand other aspects of those methods' internals. – Dan J Nov 02 '15 at 19:52
  • I will try to give a real-life example: Imagine that we downloaded a 3rd party API with its source-code, a huge source-code which is not well-developed at all because the lack of error-handlings, and as we didn't developed the huge source-coude could be a little headache to step into analysis for each "lack" on methods, then with a routine or software like this we could save A LOT of time by seeying common (or not too common) exceptions that are not handled, then handle them. – ElektroStudios Nov 02 '15 at 19:57
  • Also please note that this kind of sofware existed by popular companies such as Microsoft and RedGate, try to keep that in mind instead of searching for negative things, because there are a lot of positive things, scenearios where these tools can do a good work for the programmer, thats why these apps were developed, to help us in our needs. – ElektroStudios Nov 02 '15 at 19:58
  • 4
    Aside from academic curiosity, I still don't see the usefulness of knowing every **type** of exception thrown by a given codebase, and here's why: You can catch any exception thrown in a .NET application by catching the base `Exception` type. Whether your code can sensibly *handle* a given exception - that is, do something other than crash the process - depends on the state of the application and the nature of the exception. This is why it's more important to understand what types of exceptions your code can *handle* than what types of exceptions the code you're calling can throw. – Dan J Nov 02 '15 at 20:09

1 Answers1

1

To me that seems really hard to do. You have to know the inner working of a method before you know what exception it can throw, or you have to rely on documentation which isn't always that reliable on making clear what exceptions to expect (although Microsoft does a decent job).

You can impossibly check for a lot of common exceptions, like OutOfMemoryException. StackOverflowException, DivideByZeroException and NullReferenceException seem easier to do, but that requires to analyze the code and break it down to logic.

Patrick Hofman
  • 153,850
  • 22
  • 249
  • 325