I got my hands on ParaSofts .Test

Nunit on steriods. Uses Nunit too.

Its really screaming at :

 AppSettingsReader configReader = new AppSettingsReader();
            return configReader.GetValue(DataAccessAdapter.ConnectionStringKeyName, typeof(string)).ToString();

Seems that GetValue returns back :

ArgumentNullException and a InvalidOperationException.

which are not being handled.

Just a fyi.

My motto: always remove the bullets from the gun. That way when i do shoot myself in the foot.....

John

does the config file used by parasoft.test contain the appSettings tag? Apparently it doesn't. As with nunit, you need to specify the .config file in some way or the other.

Otis wrote:

does the config file used by parasoft.test contain the appSettings tag? Apparently it doesn't. As with nunit, you need to specify the .config file in some way or the other.

No this test looks for all untraped exceptions no matter how unlikely or bizzare they might be and tells you about them.

John

Ah ok. But keep in mind that I don't handle all exceptions that can occur in a method, because some exceptions like the ones you quoted in the context of the config file, are fatal and have to terminate the program.

What's the rest of your motto?

JMichelson wrote:

What's the rest of your motto?

I'm not sure what you mean with that question, but I look at exceptions this way: - exceptions are exceptional, as a catch-clause can't simply 'resume next'. If the exceptional state can be handled locally, and thus the exception is not fatal, handle it, try to move on - an exception which can't be handled locally (config file missing for example) will bubble upwards in the call chain. Perhaps higher up the call-chain the exception can be handled. If so, handle it, move on. Otherwise hte exception is fatal and will bubble upwards. - a fatal exception will end up in the thread-exception handled and will show a nice gui form.

There is check code in the runtime libs/generated code, for example when the user (the developer) can use it wrong because the specs allow that). There is no check code for situations not part of the interface scope. This means: if the interface is defined an input parameter for a given usage and by specifying a weird value it will break, the interface isn't used correctly. This is the case in some routines. Most routines have check code in place for parameters and throw exceptions when the input isn't correct or not complete.

A program which dumps random data in the lib and looks what it gets back might give you the idea that the lib is full of issues. Like the exceptions in your startpost. EVERY exception related to a missing file, overflow or other crap inside the file will cause a termination of the application. So the exception is fatal, and can't be handled locally. I can't handle the exception. So the code would look like:

try { AppSettingsReader configReader = new AppSettingsReader(); return configReader.GetValue(DataAccessAdapter.ConnectionStringKeyName, typeof(string)).ToString(); } catch(exception ex) { throw ex; }

or other handling mechanism which would rethrow the exception. This is the same as:

AppSettingsReader configReader = new AppSettingsReader(); return configReader.GetValue(DataAccessAdapter.ConnectionStringKeyName, typeof(string)).ToString();

.

IF I could have done something at that level, I would have handled that exception, but that's not the case.