Is This Overkill?

[Mike Hofer]

That's certainly true, and only you can decide which way the trade-off tips
for your particular API. However, the larger and more diverse the intended
developer audience for your API, the more emphasis you should be placing on
the interests of the API users versus those of the API developers.

That's a very valid point, and one well worth consideration. Even if
the code is well documented, and the end-user documentation is clear,
a user who is simply testing code may be in for a surprise when an
exception is thrown by the library and they've never worked with it
before. It's something I hadn't thought of before.

It's a shame there's no way to build or modify the stack trace to
remove the entries so that they accurate reflect the offending
routine.

See my response to Jon. The cases where the framework does this are
probably not desirable.


Are you sure that all the developers in your intended API audience are all
that competent, experienced, etc.? If so, then you have no worries.

I am expecting a *certain* degree of competence. I would expect that
anyone using this library is looking for a way to improve code
quality, much like a user who seeks out NUnit to improve code quality
through the use of TDD. However, as you've said, it's certainly going
to be interesting to see what happens when users look at the thing and
they've never seen it before, and the stack trace contains additional
entries.

Where do you get that idea? If encouraging argument validation was a
serious goal for the folks on the CLR or language teams at Microsoft,
declarative validation would have made its way out of the Spec# research pit
quite some time ago, and they would never have permitted the introduction of
automatic properties without support for declarative validation. Heck, they
could have done as little as salvaging the XC# post-compiler
(http://www.resolvecorp.com), which seems to have suffered a largely ignored
demise sometime before Visual Studio 2005 was released.

Personally, I would argue that there is next to no framework support for
doing the right thing with respect to argument validation, but then I might
just be a bit bitter...

Whoops! That was my bad! By "framework" I was referring to the
framework that I am developing. I usually refer to the .NET Framework
with "Framework" (capital F). (I'm a spelling nazi, but always forget
that this is the Internet, and it doesn't universally apply, and
others may not pick up on that.)

What I should have said was that the purpose of the framework that I
am developing is to refactor complex code. The .NET Framework itself
almost certainly *never* does this, as you well know, but gives you
the raw building blocks, and then you have to refactor the hell out of
it.

My apologies for not being clear on that.

Again, if it actually buys you nothing because your intended audience are
sufficiently sophisticated, then it's probably not worthwhile. However,
it's not actually all that much more work to put the throws in the target


There's a way to avoid the impact on the stack trace, but it's terribly
inelegant and would require adding more code to the target method. However,
just for the sake of completeness, here it is...

Since the call stack for an exception is generated when it is thrown, your
target method would wrap its validation method calls in a try catch that
explicitly rethrows any caught argument exceptions. e.g.:

Try
Validate.That(siteId, "siteId").IsNotNegative()
Validate.That(name, "name").IsNotNullOrEmpty()
Validate.That(buildingIdToIgnore,
"buildingIdToIgnore").IsGreaterThan(-2)
Validate.That(connection).IsOpenAndIsNotNull()
Catch ex As ArgumentException
Throw ex
End Try

Personally, I think it's far less palatable than the alternatives, but
ymmv...

Just brainstorming here, but let me run this by you. Since I can't
modify the stack trace itself, and since I don't want additional
information in it, what if I used a custom exception class, such as a
ParameterValidtationException, and that class shadowed the StackTrace
property. I could then rewrite the stack trace so that I could fetch
it, remove the extra entries, and then expose the cleaned list to the
end user? Further, I could then extend that class with specific
exception types, if need be, to mimic the standard argument
exceptions.

It might have several advantages: most notably, it keeps the stack
trace clean, but it also tells you explicitly that the exception was
thrown by the validation framework. With some optimization, the code
to clean the stack trace can be kept clean, small, and fast.

Thoughts?

 

[KKS]

Just brainstorming here, but let me run this by you. Since I can't
modify the stack trace itself, and since I don't want additional
information in it, what if I used a custom exception class, such as a
ParameterValidtationException, and that class shadowed the StackTrace
property. I could then rewrite the stack trace so that I could fetch
it, remove the extra entries, and then expose the cleaned list to the
end user? Further, I could then extend that class with specific
exception types, if need be, to mimic the standard argument
exceptions.

It might have several advantages: most notably, it keeps the stack
trace clean, but it also tells you explicitly that the exception was
thrown by the validation framework. With some optimization, the code
to clean the stack trace can be kept clean, small, and fast.

Thoughts?

Is this really that important? It seems to me now that you creating a lot of
work for yourself. Just my opinion.

Regards
Kjetil

 

[dbahooker]

finally someone else sees the fallacy of using XML

 

[Mike Hofer]

finally someone else sees the fallacy of using XML






- Show quoted text -

No one even mentioned using XML. Certainly not me. Troll somewhere
else, please.

 

[Mike Hofer]

Is this really that important? It seems to me now that you creating a lot of
work for yourself. Just my opinion.

Regards
Kjetil- Hide quoted text -

- Show quoted text -

I'm not sure. I just want to make sure that I've covered all my bases.
If enough users think that it would be a big enough concern, then I'd
want to make sure it wasn't going to be a substantial enough deterrant
to prevent its use, and handle that. But I'd only do so if the
implementation didn't destroy the usefulness of the library.

Also, I don't think it would be that much work to do it, especially if
it provided clarity to the end-user. Clarity, in my eyes, is a Very
Good Thing, and it's worth the up-front effort on my part if it
provides a larger return on my investment down the road. Not just for
myself, mind you, but for everyone who might use it.

But again, therein lies the rub: Does it provide clarity and
usefulness? If it does, then I'd do it. If it doesn't, then I wouldn't.

 

[Nicole Calinoiu]

I am expecting a *certain* degree of competence. I would expect that
anyone using this library is looking for a way to improve code
quality, much like a user who seeks out NUnit to improve code quality
through the use of TDD.

What about their API users, who will be the ultimate consumers of exceptions
generated from your framework? Besides potentially not fitting the expected
profile for users of your library, they'll also be blissfully unaware that
your validation framework is even being used by the API they are invoking.

Just brainstorming here, but let me run this by you. Since I can't
modify the stack trace itself, and since I don't want additional
information in it, what if I used a custom exception class, such as a
ParameterValidtationException, and that class shadowed the StackTrace
property. I could then rewrite the stack trace so that I could fetch
it, remove the extra entries, and then expose the cleaned list to the
end user? Further, I could then extend that class with specific
exception types, if need be, to mimic the standard argument
exceptions.

Unfortunately, swapping out the exception type is going to be a breaking
change for existing code. For example, an existing catch block that handles
System.ArgumentNullException won't catch your ParameterValidationException
or a derived
ParameterNullException. You could work around this by subclassing the
built-in specific exception types and adding your stack trace manipulation
via composition.

It might have several advantages: most notably, it keeps the stack
trace clean, but it also tells you explicitly that the exception was
thrown by the validation framework.

Users of the APIs produced by users of your framework probably won't want to
see any difference between the exceptions it throws and any other argument
exceptions they might need to handle.

With some optimization, the code
to clean the stack trace can be kept clean, small, and fast.

And able to handle stack traces generated in languages other than English?

 

[Mike Hofer]

What about their API users, who will be the ultimate consumers of exceptions
generated from your framework? Besides potentially not fitting the expected
profile for users of your library, they'll also be blissfully unaware that
your validation framework is even being used by the API they are invoking.

Third, fourth, and fifth generation users, then? I hadn't thought of
that. Good catch.

Unfortunately, swapping out the exception type is going to be a breaking
change for existing code. For example, an existing catch block that handles
System.ArgumentNullException won't catch your ParameterValidationException
or a derived
ParameterNullException. You could work around this by subclassing the
built-in specific exception types and adding your stack trace manipulation
via composition.

Okay, that works.

Users of the APIs produced by users of your framework probably won't want to
see any difference between the exceptions it throws and any other argument
exceptions they might need to handle.

I'll buy that, with one caveat: In my limited experience, there's
alway the edge case that proves my expectations wrong. I'd at least
want to provide *some* way to let users know that the exception was
thrown from my framework, and not directly from within their code.

And able to handle stack traces generated in languages other than English?

Another very good point. I was actually thinking of making this open
souce once I got the base stuff done, and since I know little to
nothing about proper globalization (yeah, it's a gaping hole in my
skillset), I figured that others could help me cover that ground. I
don't pretend for an instant that I know everything, or even the vast
majority of all that there is to know about the proper or best way to
do this. It's why I started this thread in the first place. And your
insights have been invaluable. Thank you very much.

 

[Nicole Calinoiu]

If you're willing to put a bit of work into this, you might want to consider
going the post-compiler route instead in order to allow declarative
validation. A few years ago, I was thinking of doing some similar stack
trace manipulation when I ran across XC#. Unfortunately, given that you're
targeting VB, you wouldn't be able to use XC# even if it were still
available. However, there does appear to be a more general .NET
post-compiler available at http://www.postsharp.org/. I'll be taking a
closer look at it myself as soon as I get a chance, but it does look like a
reasonable candidate for enabling declarative validation if it lives up to
its promise...

 

[Guest]

I don't think that we should ever use 'XML' and 'Architected' in the
same sentence

XML is for retards that don't have the capacity to learn SQL


it's SLOWER and LARGER with no tangible benefits

Joke of the day!