Framework Design Guidelines: Powerful and Easy

re: Framework Design Guidelines: Powerful and Easy

Sean Chase — Sat, 08 Oct 2005 01:16:41 GMT

throw new System.Exception("yuck");

re: Framework Design Guidelines: Powerful and Easy

Matthew W. Jackson — Sat, 08 Oct 2005 09:10:24 GMT

I'll second the Exception one. If you had it to do again, I'd say make System.Exception abstract, make all the exceptions that shouldn't be caught (such as ThreadAbortException or StackOverflowException) inherit from a single base (like AsyncException), and everything else could be a SystemException. Also, the ArgumentExceptions would be more consistant and useful.

Anyway, the big easy-to-misuse API I stumbled upon yesterday was Type.InvokeMember when late-binding COM objects. Specifically I'm talking about the "ParameterModifier[] modifiers" argument for marking arguments as by-reference. The usage of this is simply esoteric.

Then again, a lot of things in Reflection are this way.

re: Framework Design Guidelines: Powerful and Easy

Jonathan Allen — Sat, 08 Oct 2005 19:32:15 GMT

I for one have completely given-up on reflection. I need to use late binding because some COM classes are so poorly written that none of their interfaces appear to list all the methods I know exist.

Even though out company is mostly C#, we decided to write all the interop code in VB instead of dealing with the reflection directly.

For example, Rational's ClearQuest API. None of the interfaces listed in the object browser for the Entity object expose the EditEntity method. But yet VB somehow figures out how to call it anyways.

Can tell me how VB does that?

Jonathan

re: Framework Design Guidelines: Powerful and Easy

Abubakar — Mon, 10 Oct 2005 07:40:59 GMT

well I wrote a code using anonymous methods, and it was the only time I didnt like my code.

re: Framework Design Guidelines: Powerful and Easy

Geert Baeyaert — Mon, 10 Oct 2005 11:22:36 GMT

I think WeakReference.IsAlive is an example of a mountain of success.

Consider the following example:

foreach (WeakReference wr in wrs)
{
if (wr.IsAlive)
{
// GC happens here
((Foo)wr.Target).Bar();
}
}

Bam, NullReferenceException, hard to reproduce, hard to find.

Actually, I can't think of one example where WeakReference.IsAlive is usefull. You always have to check that the target is not null, as in the following example:

foreach (WeakReference wr in wrs)
{
Foo foo = (Foo)wr.Target;
if (foo != null)
{
foo.Bar();
}
}

Therefore, I think WeakReference.IsAlive should be made obsolete.

(I have already submitted this on the Feedback center, vote for it if you agree with me)

What's wrong with ASP.NET? HTML encoding

I may have joined the wrong side — Wed, 28 Jun 2006 21:47:16 GMT

The problem
Back when ASP.NET was first introduced, I had pretty high hopes that the new controls would...

What's wrong with ASP.NET? HTML encoding

I may have joined the wrong side — Sun, 09 Dec 2007 16:10:54 GMT

The problem Back when ASP.NET was first introduced, I had pretty high hopes that the new controls would

Brad Abrams Framework Design Guidelines Powerful and Easy | Paid Surveys

Brad Abrams Framework Design Guidelines Powerful and Easy | Paid Surveys — Fri, 29 May 2009 01:58:45 GMT

PingBack from http://paidsurveyshub.info/story.php?title=brad-abrams-framework-design-guidelines-powerful-and-easy

Brad Abrams Framework Design Guidelines Powerful and Easy | internet marketing tools

Tue, 16 Jun 2009 08:29:32 GMT

PingBack from http://einternetmarketingtools.info/story.php?id=7448