博客园-倚栏望海集

校验从Outlook2007/2010beta发出的邮件（VS2010beta2， dot Net 3.5 & dot Net 4.0）

Aaron@cnblogs — Sun, 01 Nov 2009 10:43:00 GMT

阅读: 42 评论: 0 作者: Aaron@cnblogs 发表于 2009-11-01 18:43 原文链接

原因

最近收发的邮件越来越敏感。虽然自己小心翼翼但是有时候难免会发错，不过好记性不如烂笔头。决定花点时间研究一下如何在Outlook发邮件之前做一些必要的校验。要检验的是两个问题：

1. 我的工作环境是公司有自己的邮件系统，客户有另外一个邮件系统。因为我们在工作中和客户的系统是紧密相联的，部门中包括VP都有客户给的邮箱。而且，客户的邮件系统和Outlook结合的更好。所以，往往为了省事，大部分员工优先使用客户邮箱沟通所有的事情。但是，有些内容会涉及到本公司内部的信息，这是不应该使用客户邮箱来沟通的。

2. 发工作邮件没有标题是很糟糕的。虽然我极少犯此错误（印象中没有试过），但是犯错一次可能会有严重的不良影响。

工具

VS2010beta2，Outlook 2007/2010beta，VSTO 40，.Net Framework 3.5/4.0 beta2

VS2010beta2已经完成所有的功能开发，剩下的工作只是性能调优。所以，生成的代码应该可以无缝地RTM中继续使用。虽然不知道 .Net Framework 4.0什么时候发布，但VS2010是可以创建以前版本的工程文件。所以，为了使用者不需要安装临时的 .Net 4.0 beta，可以用 .Net 3.5配合 VSTO40创建功能。用户可以减少安装负担。

VSTO 40是随VS2010发布的针对Office的interop组件。

实现

其实没有什么技术含量。虽然从来没有使用过VSTO，网上的资料也不是很全，但2个小时基本上调试完成。共享出来的原因也就是为了减少大家搜索的时间而已。

ThisAddin.cs

整个代码没什么神奇的地方。不再做详细的解释。这段代码也可以直接用在 .Net Framework 4.0的工程中。两者在本例并没有区别。

ViolateVITSensitive用来校验是否有违规的邮件地址。比如发件者的邮箱是alias@domain1.com。那么就不允许出现XXX@domain2.com 的收件人。发现违规会弹出提示，用户可以取消或者强制发送。

代码有不少可以优化的地方，比如所有的校验函数都可以做成DI（IoC）的模式（不过暂时没有必要。而且，这样只会扰乱只关心怎么用VSTO的读者）。

XML部分可以用lambda，不过我对这种在大部分情况只提高书写效率，并不会提高执行效率和调试效率的东西不太感冒（也可能是个人偏见，呵呵）。

评论: 0　查看评论　发表评论

最新新闻：
· 苹果iPad或将内置摄像头公司招聘启事暗示(2010-02-10 11:43)
· Google Buzz的优缺点分析(2010-02-10 11:39)
· 京东商城刘强东：两个回合谈定1.5亿美元融资(2010-02-10 11:30)
· Google走到关键时刻：Buzz发布的背后(2010-02-10 11:30)
· 李开复创新工场发展基金曝光首单投移动互联(2010-02-10 11:28)

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

The implementation of IDisposable Pattern of System.Net.NetworkInformation.Ping may be wrong

Aaron@cnblogs — Thu, 22 Oct 2009 16:59:00 GMT

阅读: 1038 评论: 2 作者: Aaron@cnblogs 发表于 2009-10-23 00:59 原文链接

Ping class as expected holds an unmanaged resource viewed via reflector. In most cases, as i know, the class implements an explicit IDisposable.Dispose method. And Ping does it the same way as others, like EventWaitHandle. But unlike EventWaitHandle, it also inherits Component, an implementation class, which implements an implicit Dispose from IDisposable. As an outsider, i am surprising to compose my code like this:
Ping p = new Ping();
//...
p.Dispose();
As the Component class follows standard IDisposable pattern. There is a protected virtual Dispose(bool) method inside it. An interesting observation is the Ping doesn't override that protected method and implment the explicit IDisposable.Dispose as follow:
//from reflector (.net 2.0)
void IDisposable.Dispose()
{
InternalDispose();
}

The InternalDispose() just closes everything and returns.

So if anyone acts like me, call Ping.Dispose() will get unexpected result.

I just got a reply from MSFT (Tratcher, a System.Net developer in Windows Core Networking) that "Your observations are correct. This has been fixed in .Net 4.0 Beta 2, which was released this week. Take a look and let us know what you think."

At last, I just got my beta 2 installed today. It looks pretty good. :)

评论: 2　查看评论　发表评论

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

淡

Aaron@cnblogs — Tue, 15 Sep 2009 16:22:00 GMT

阅读: 37 评论: 0 作者: Aaron@cnblogs 发表于 2009-09-16 00:22 原文链接

云居虚境高

线撒湖边钓

蜓立杆头摇

茶香径上草

于二零零九年九月十六日零时一分

评论: 0　查看评论　发表评论

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

老事重提--命名规范（Name Notation）

Aaron@cnblogs — Thu, 03 Sep 2009 02:50:00 GMT

阅读: 106 评论: 0 作者: Aaron@cnblogs 发表于 2009-09-03 10:50 原文链接

如果读者已经加入某个软件公司开始编码，应该已经接触到贵公司的命名规范。一般规范都会解释怎么做，解释为什么的估计会比较少。在本节中笔者尽所能，去挖掘这些命名规范是什么，规范确立的缘由，并且从哪里来的。不过有的缘由已经失落难以寻找，有的可能没有多少理由。有错漏之处，请多多指点。

命名法中对Windows影响最深远的就是匈牙利命名法（Hungarian Notation，HN。参见中文维基百科的“匈牙利命名法”主题（http://zh.wikipedia.org/wiki/匈牙利命名法）或者英文主题“Hungarian Notation”（http://en.wikipedia.org/wiki/Hungarian_notation）），由Charles Simonyi（http://en.wikipedia.org/wiki/Charles_Simonyi）在微软的期间（1981~2002）开始迅速推广的命名规则。因为这套规则前缀并不都是英文，其规则是“类型+变量名”，类似于匈牙利人“姓氏+人名”（和中国人一样），与一般欧洲人习惯（“变量名+类型”）不同，Charles又是匈牙利人，所以称为匈牙利命名法。这个命名法又分为“Systems Hungarian”（系统匈牙利）和“Apps Hungarian”（应用匈牙利）。Systems Hungarian基于变量的Type（类型），而Apps Hungarian基于Purpose/intent（意图）。比如：

//Systems Hungarian

UInt32 unIndex; // or dwIndex. An index of UInt32 type

LPWSTR lpwszName; // a long distance point widechar zero-terminated String

// LPWSTR is a Windows C type, not existing in C#.

//Apps Hungarian

Int32 arrIndex; // An index of an array

string szName;

//Recommended as the alternate notation of Apps Hungarian

Int32 indexOfArray;

string nameString; // or nameStr

最后两个indexOfArray和nameString是现在不少人比较提倡的命名法，用来代替Apps Hungarian。其它比较出名的前缀，如“sz”，表示以空零结尾的字符串（“sz”实际上是匈牙利字母表中的一个合体字母，例如，szName，表示字符串Name。因为没有指明字符串是如何组成，这个是Apps Hungarian。如果写成lpcwszName，lp：长跳转指针，c：const，w：宽字符，sz：空零结尾字符串，则是Systems Hungarian），如全局变量用“g_”前缀，类成员变量用“m_”。这套命名规范已经被.Net摒弃（参见MSDN上“General Naming Conventions”主题），但在微软内外还有不少人用，而且还经常出现在C#的代码中（包括笔者）。所以，有必要拉出来讨论一下在C#的优缺点。

Hungarian Notation（HN）	C#上的代替方案
[优点]通过肉眼就能分辨变量类型，而无需向上翻页去找变量的声明定义。	把鼠标放到变量上即可看到变量类型，而且在强类型语言中在变量加类型前缀显得冗余。
[优点]多个语意类似的变量可以在一起使用，减少命名冲突。比如UI编程的时候，TextBox（输入框）为txtUserName，Label（提示框）为lblUserName。	笔者在UI编程的时候还是遵循这套规则。可以用“变量名+控件名”的方式，如userNameTextBox。
[优点]（Apps Hungarian）当作不恰当赋值的时候，可以肉眼判断。在Joel Spolsky的文章“Making Wrong Code Look Wrong”（http://www.joelonsoftware.com/articles/Wrong.html）有精辟的阐述。简要说明一下。假设有如下代码： int hWindow = GetWindowWidth(); 其中“h”前缀表示“height”。明显用肉眼就能看到这个赋值有问题，应该是： int wWindow = GetWindowWidth(); 或者 int hWindow = GetWindowHeigth();	按照camelCasing（驼峰命名法），可以这样写： int WidthOfWindow = GetWindowWidth(); 或者 int windowWidth = GetWindowWidth();
[优点] （特指Systems Hungarian）代码量很大的情况下，（如UI编程中）可以更容易找到所要变量。例如要找的变量的类型是TextBox（输入框，缩写为txt），但记不清楚变量名后缀是UserName还是User，可以敲txt然后按“ctrl+j”在代码提示中选择。	这是笔者在UI编程中使用HN的另外一个原因。
[缺点]在泛型编程中是无法在编写代码的时候确定变量类型的。	问题同样存在。
[缺点]（特指Systems Hungarian）当变量类型改变的时候需要在变量出现过的地方逐个修改，特别是一些比较常用的变量名会让查找修改变得困难。	问题同样存在。

匈牙利命名法（Hungarian Notation，HN）的历史故事

Charles Simonyi在微软内部推行的HN其实是Apps Hungarian，但是却被内部文档人员误传（参见Larry Osterman博客的文章“Hugarian notation - it's my turn now :)”（注：Larry的原文把Hungarian写成Hugarian），链接：http://blogs.msdn.com/larryosterman/archive/2004/06/22/162629.aspx。还有Rick Schaut的文章“Hungarian Notation”，链接：http://blogs.msdn.com/rick_schaut/archive/2004/02/14/73108.aspx），结果导致Systems Hungarian在内部泛滥。加上Charles Petzold曾经“大力”传播Systems Hugarian（参见Charles Petzold的文章“The Demise of Hungarian Notation”，链接：http://www.charlespetzold.com/blog/2006/05/040939.html），导致很多程序员错误的使用了很长一段时间。笔者倒是不反对Apps Hungarian，只要约定明晰，还是很好用。特别是在一个函数内出现多个语意相同的变量会显得更加简洁明了。比如在获取Name字符串变量的操作时可能会需要如下变量：szName（字符串Name），iName（Name字符串的index）。代码如下：

string szName = "Charles Simonyi";

int iName = szName.IndexOf(' ');

string firstName = szName.Substring(0, iName);

微软推荐的编程风格请参阅MSDN中的“Guidelines for Names”主题。简单概括如下。

类型	规则
namespace（命名空间），interface（接口），class（类），property（属性），method（方法）	遵循PascalCasing，即首字母大写，然后每个单词的首字母都是大写
namespace（命名空间），interface（接口），class（类），property（属性），parameter（参数）、local variable（局部变量）	都由名词或者动名词组成
interface（接口）	由“I+名词”组成
method（方法）	由“动词+名词”组成
parameter（参数）、local variable（局部变量）	遵循camelCasing，即首字母小写，从第二个单词开始首字母大写

但是MSDN上并没有内部成员的命名规范。大概是觉得内部成员，编程人员可以自行规定。笔者曾经工作过的一个部门有一位高级开发人员，他当时在写一个相当复杂的功能。其伪代码片段如下：

class RealCaseStudy

{

// member variable

private string usrId;

//...other code

private void DoAComplexCalculation()

{

//local variable usrId. It is a typo.

string userId = String.Empty;

//some complex code

//...

// Actually should use the member variable

// 'usrId' here.

userId = CallAnotherMethod();

// other complex code

}

因为这个DoAComplexCalculation方法本身很复杂、很长，谁没有留意有一个局部变量“userId”和成员变量“usrId”只差一个字符。结果在应该给成员变量赋值的地方，错赋给局部变量。这个小小的typo（打字错误）让他的调试工作毫无进展并牵动了很多资源，结果还让整个进度完了一周，最后才由另外一位程序员发现解决。他当时很可能是把局部变量移到到成员变量的时候少敲一个字符。在赋值的时候，敲“us”出现的代码提示中局部变量先于成员变量。因为两个变量本来就是代表同一个意思，开发者并没有仔细查看选中变量，从而导致天大的失误。这正是所谓的“细节决定成败”。如果他遵循良好的命名规范，这个问题自然就会被避开。解决的方法有两种：

1.“this.[memberVariable]”

2.“_[memberVariable]”

两者没有本质的区别，只是习惯体验不同。笔者采用的是方法二。好处就是简单，只需要敲一个字符“_”就可以按照代码提示选择正确的成员变量，而方法一需要多敲几个字符才能获得代码提示。要是算上删除这5个字符，如果还要修改，工作量起码翻倍。下划线不好的地方是看起来奇怪。读者可以自行选择自己喜欢的方式。笔者也在网上见过的一些大侠用“this.m_[xxXx]”的，这个双保险有点画蛇添足（或者说Over-Kill）。“m_”在MFC中非常常见，但对于C#这个没有全局变量，即，不会用到“g_”前缀（global）；没有局部静态变量，即，不会用到“s_”前缀（static）的语言来说，用“m_”前缀明显没有意义。因为没有其它语意干扰单个“_”前缀代表成员变量的语意。下面简要总结笔者在本书中采用的命名规范：

1. 首选MSDN上的规则（即Pascal/Camel规则）；

2. 在UI编程时，控件对应的变量依然用Systems Hungarian；

3. 成员变量遵循“_[memberVariable]”;

4. 只读（static readonly）的简单类型用“全大写名词+[_全大写名词]”

如果读者不喜欢条款2，网上提倡的代替方式是用“变量名+控件名”，如“nameTextBox”（变量名：name+控件名：TextBox）。一般来说，大家都按照一个规范来做，持之以恒，也没什么大碍。只是写代码是天天都要做的事情，也应该知道这些规矩的来龙去脉。这些细节积小成多，可能会导致很不一样的结果。另外，让笔者小惊讶的是搜中文资料（Google或者Baidu）时发现除了中文版的维基百科，几乎都只是提到Systems Hungarian，而且似乎流传多年的版本都是出自同一个人之手。也许是看英文的懒得转载，看中文的从来不会想到去看个究竟。

--摘自我新出书的一节

评论: 0　查看评论　发表评论

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

VS.Net 2005, VSS 2005, SQL SERVER 2005 Released, Inner Available

Aaron@cnblogs — Tue, 01 Nov 2005 02:53:00 GMT

阅读: 746 评论: 0 作者: Aaron@cnblogs 发表于 2005-11-01 10:53 原文链接

注意，卸载VS.NET 2005 peta 需要专门的工具，不然很容易卸坏了。
我的同事悄悄放下Test Case开始疯狂安装了，哈哈

评论: 0　查看评论　发表评论

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

也说VS.Net 下的 IContainer, IComoponent, ISite

Aaron@cnblogs — Fri, 25 Mar 2005 09:28:00 GMT

阅读: 1019 评论: 0 作者: Aaron@cnblogs 发表于 2005-03-25 17:28 原文链接

最近老在 asp.net 的技术上转悠就看到这三个接口。google了一下，很多设计模式的东西挖都出来。。不过不论别人是怎么用的。在 ms 的 Web 设计中，System.Web.UI.WebControl 都是 IComponent，或者说都是从这个接口继承的。VS.Net 设计器本身实现 IContainer，它可以拥有多个Component，而每一个设计图面是ISite。一个设计视图只能有一个Component？下面有个window Form 的结构图。Web Form 的模式应该差不多。但我看来看去还是不明白这个ISite在哪，有什么用？更准确的说有什么不可替代的地方？

评论: 0　查看评论　发表评论

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

臆说道学儒家

Aaron@cnblogs — Mon, 07 Mar 2005 02:25:00 GMT

阅读: 716 评论: 0 作者: Aaron@cnblogs 发表于 2005-03-07 10:25 原文链接

人一天天长大老去，自然对于自己的经历有个看法。这些看法对于后人来说则是宝贵的经验。只是能把这些经验说清楚很不容易。如果还真有人说明白过，就算是老子。他只用五千子就把问题说得很透彻。旧时一般说外用儒家内用道学。内用就是自己用的，没法对别人说；或者很难说个透彻；或者是很难比老子说的透彻。几千年过去，几个大的学说中，唯独道学发展缓慢，甚少推陈出新。这也许因为老子说得太绝。也许也因为如此，老子说完後就悄悄归隐————他已无话可说。老子的话太真，只能自用，自己领会，难以宣扬。加上老子后来的归隐，使得后世臆断道学就是归隐、退缩、避世的代名词，可叹可惜。也许孔子也看到这一点。知道世人愚昧，能领悟者寥寥，等到这些人能领悟之时已经徐徐老已，晚了。孔子便耗尽心机，想出一套罗嗦繁杂的教条规章制度来让世人练习。虽然后人难以跳出孔子的论说，但规章制度很容易发展完善。后世众生就在此上做文章，大显身手。特别在宋朝出了儒家大闲人，别的不干把三从四德发展到无微不至，让人敬仰膜拜。太过就不得自然，违背一般法则必然会受到惩罚。宋在内部发展上达到了一个极至，但是忽略外部的强敌，怎个不亡？

评论: 0　查看评论　发表评论

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

看了一下VS2005对托管C++的修正

Aaron@cnblogs — Fri, 25 Feb 2005 08:08:00 GMT

阅读: 869 评论: 0 作者: Aaron@cnblogs 发表于 2005-02-25 16:08 原文链接

原文连接：http://blog.sunmast.com/sunmast/articles/860.aspx

我的一些看法：
用 gcnew 是个好主意。

看到这个比较兴奋：
引用类型在堆栈上 ReferenceType h;
处理Dispose的方式也还不错：
调用Dispose 方法 ReferenceType^ h = gcnew ReferenceType;
delete h;

这个也可以接受：
调用Dispose 方法 ReferenceType^ h = gcnew ReferenceType;
delete h;

但是这样
ref class ReferenceType {};
value class ValueType {};
不见得比
__gc class ReferenceType {};
__value class ValueType {};
高雅。或者说一样垃圾。除非 ref/value 可以省略。对于class 缺省应该是ref，对于 struct缺省应该是 value。

不过最让我感到恼火同时也感到欣慰的是：

public ref class ReferenceType
{
    public:
    // 程序集内部和外部同时可以访问
    private public:
    // 仅程序集内部可以访问
    protected public:
    // 程序集外部仅继承了的类型可以访问，内部代码可以直接访问
};

的确，这样对访问的控制更精确了。。。但是*——#……%—%86

新的box和un-box还是可以接受。新的属性处理的确比原来的好多了。但是

property String^ Name
{
    String^ get()
    {
        return m_value;
    }
    void set(String^ value)
    {
        m_value = value;
    }
}

还是太罗嗦。这个property 本来就是特殊处理。那么Get当然是返回property那行的类型。set的输入参数也肯定是相同的类型。而且也肯定没有返回值。所以，上面的例子完全应该：

property String^ Name
{
    get()
    {
        return m_value;
    }
    set()
    {
        m_value = value;
    }
}

总体来说，好消息比坏消息多了点。

评论: 0　查看评论　发表评论

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

春节广州西关行

Aaron@cnblogs — Wed, 23 Feb 2005 05:59:00 GMT

阅读: 1158 评论: 5 作者: Aaron@cnblogs 发表于 2005-02-23 13:59 原文链接

春节回家闲来无事决定转转西关，感受一下岭南昔日独有的民风和建筑。不用多说，跟着我的相机浏览一下复原的西关大屋。

带西洋教堂花窗的门。当时广州是对外贸易的重要港口，这些舶来之物随处可见。

花厅的一角。花厅也就是正厅。

床沿。花厅后面是主人房。这个上百年历史的床还是像新的一样。

少爷房的外面。复原大屋的少爷房在二楼，旁边就是小姐的房间。可惜那里光线不好没拍什么好东西。

精美的花窗。

评论: 5　查看评论　发表评论

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

你会重抛异常(re-throw Exception)不？

Aaron@cnblogs — Fri, 14 Jan 2005 17:01:00 GMT

阅读: 3013 评论: 3 作者: Aaron@cnblogs 发表于 2005-01-15 01:01 原文链接

重抛异常(re-throw Exception)
我一直以来就是这样写代码：

01: public void ThrowFunction()
02: {
03:    //Initialize
04:    String errMessage = "Just sample throwing.";
05:    Boolean isSomeWrong = true;
06:    //do something
07:    if(isSomeWrong)
08:      throw new Exception(errMessage);
09: }
10:
11: public Object GetSomeReturn()
12: {
13:   Object ret = null; // return value.
14:   Object someObj = null; // local value.
15:
16:   try
17:   {
18:      //Initialize
19:      ret = new Object();
20:      somObj = new Object();
21:      // do some thing
22:      ThrowFunction();
23:   }
24:   catch(Exception e)
25:   {
26:      // Clean up return value.
27:      if(ret != null) { ret.Dispose(); ret = null; }
28:      throw e;
29:   }
30:   finally
31:   {
32:      if(somObj != null) { somObj.Dispose(); somObj = null; }
33:   }
34:   return ret;
35: }

怎么看都好像没问题，msdn也是这样写的，连Java都是这样写的。但在总是在上一层的
catch中发现少了些信息。最近搜索到一篇文章才发现我正正写错了2年。而且，文章提
到的书也颇有名气。问题在哪？就在于"throw e"。这些写打断了错误栈（stack）链
（break the exception chain or exception stack trace）。如果你查看这个
Exception变量的StackTrace属性：
Exception: System.Exception: "Just sample throwing."
at XXX.GetSomeReturn() in YourProgramPath\SourceCodeName.cs:line 18

是line:28。但是就丢失了关于ThrowFunction发生的事。实际上如果这不是你要的结
果，你只要把28行改为'throw;'即可。如果你catch exception仅仅为了clean-up。
还可以把24行改为'catch(Exception)' 甚至'catch'。最懒惰的写法就是：

01: public void ThrowFunction()
02: {
03:    //Initialize
04:    String errMessage = "Just sample throwing.";
05:    Boolean isSomeWrong = true;
06:    //do something
07:    if(isSomeWrong)
08:      throw new Exception(errMessage);
09: }
10:
11: public Object GetSomeReturn()
12: {
13:   Object ret = null; // return value.
14:   Object someObj = null; // local value.
15:
16:   try
17:   {
18:      //Initialize
19:      ret = new Object();
20:      somObj = new Object();
21:      // do some thing
22:      ThrowFunction();
23:   }
24:   catch
25:   {
26:      // Clean up return value.
27:      if(ret != null) { ret.Dispose(); ret = null; }
28:      throw;
29:   }
30:   finally
31:   {
32:      if(somObj != null) { somObj.Dispose(); somObj = null; }
33:   }
34:   return ret;
35: }

当然如果你想重新包装你的异常，则：

01: public void ThrowFunction()
02: {
03:    //Initialize
04:    String errMessage = "Just sample throwing.";
05:    Boolean isSomeWrong = true;
06:    //do something
07:    if(isSomeWrong)
08:      throw new Exception(errMessage);
09: }
10:
11: public Object GetSomeReturn()
12: {
13:   Object ret = null; // return value.
14:   Object someObj = null; // local value.
15:
16:   try
17:   {
18:      //Initialize
19:      ret = new Object();
20:      somObj = new Object();
21:      // do some thing
22:      ThrowFunction();
23:   }
24:   catch(Exception e)
25:   {
26:      // Clean up return value.
27:      if(ret != null) { ret.Dispose(); ret = null; }
28:      throw new YourException("Your costum error message",e);
29:   }
30:   finally
31:   {
32:      if(somObj != null) { somObj.Dispose(); somObj = null; }
33:   }
34:   return ret;
35: }

上面的写法：
throw new YourException("Your costum error message",e);
同样不会打断stack trace。比如需要Log下异常然后重抛该异常而不打断stack trace。
可以这样写：
01: public void ThrowFunction()
02: {
03:    //Initialize
04:    String errMessage = "Just sample throwing.";
05:    Boolean isSomeWrong = true;
06:    //do something
07:    if(isSomeWrong)
08:      throw new Exception(errMessage);
09: }
10:
11: public Object GetSomeReturn()
12: {
13:   Object ret = null; // return value.
14:   Object someObj = null; // local value.
15:
16:   try
17:   {
18:      //Initialize
19:      ret = new Object();
20:      somObj = new Object();
21:      // do some thing
22:      ThrowFunction();
23:   }
24:   catch(Exception e)
25:   {
26:      // Clean up return value.
27:      if(ret != null) { ret.Dispose(); ret = null; }
28:      YourLogClass.LogException(e);
29:      throw;
30:   }
31:   finally
32:   {
33:      if(somObj != null) { somObj.Dispose(); somObj = null; }
34:   }
35:   return ret;
25: }

Link
Read the original article about re-throw exception.

评论: 3　查看评论　发表评论

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

博客园-倚栏望海集

校验从Outlook2007/2010beta发出的邮件（VS2010beta2， dot Net 3.5 & dot Net 4.0）

The implementation of IDisposable Pattern of System.Net.NetworkInformation.Ping may be wrong

淡

云居虚境高 线撒湖边钓 蜓立杆头摇 茶香径上草 于 二零零九年 九月十六日 零时一分

老事重提--命名规范（Name Notation）

VS.Net 2005, VSS 2005, SQL SERVER 2005 Released, Inner Available

也说VS.Net 下的 IContainer, IComoponent, ISite

臆说道学儒家

看了一下VS2005对托管C++的修正

春节广州西关行

你会重抛异常(re-throw Exception)不？

云居虚境高

线撒湖边钓

蜓立杆头摇

茶香径上草

于二零零九年九月十六日零时一分