#网赚程序

【转】编写高质量代码改善C#程序的157个建议——建议71:区分异步和多线程应用场景

 建议71:区分异步和多线程应用场景初学者有时候会将异步和多线程混为一谈。如果对它们之间的区别不是很清楚,很容易写出下面这样的代码:privatevoidbuttonGetPage_Click(objectsender,EventArgse){Threadt=newThread(()=>{varrequ...

【转】编写高质量代码改善C#程序的157个建议——建议70:避免在调用栈较低的位置记录异常

 建议70:避免在调用栈较低的位置记录异常并不是所有的异常都要被记录到日志,一类情况是异常发生的场景需要被记录,还有一类就是未被捕获的异常。未被捕获的异常通常被视为一个Bug,所以,对于它的记录,应该被视为系统的一个重要组成部分。最适合记录异常和报告的是应用程序的最上层,这通常是UI层。假设存在这样一个应用程...

【转】编写高质量代码改善C#程序的157个建议——建议69:应使用finally避免资源泄漏

 建议69:应使用finally避免资源泄漏除非发生让应用程序中断的异常,否则finally总是会先于return执行。finally的这个语言特性决定了资源释放的最佳位置就是在finally块中;另外,资源释放会随着调用堆栈由下往上执行。下面的代码验证了这一点,先定义一个需要释放的类:classClassS...

【转】编写高质量代码改善C#程序的157个建议——建议68:从System.Exception或其他常见的基本异常中派生异常

 建议68:从System.Exception或其他常见的基本异常中派生异常微软建议:从System.Exception或其他常见基本异常之一派生异常。在VisualStudio中输入Exception,然后按快捷键Tab,VS会自动创建一个自定义异常类:[Serializable]publicclassMy...

【转】编写高质量代码改善C#程序的157个建议——建议67:慎用自定义异常

 建议67:慎用自定义异常 除非有充分的理由,否则不要创建自定义异常。如果要对某类程序出错做特殊处理,那就自定义异常。需要自定义异常的理由如下:1)方便测试。通过抛出一个自定义的异常类型实例,我们可以使捕获的代码精确的知道所发生的事情,并以符合的方式进行恢复。2)逻辑包装。自定义异常可以包装多个其他...

【转】编写高质量代码改善C#程序的157个建议——建议66:正确捕获多线程中的异常

 建议66:正确捕获多线程中的异常多线程的异常处理需要采用特殊的方式。一下这种方式会存在问题:try{Threadt=newThread((ThreadStart)delegate{thrownewException("多线程异常");});t.Start();}catch(Exceptionerror){M...

【转】编写高质量代码改善C#程序的157个建议——建议65:总是处理未捕获的异常

 建议65:总是处理未捕获的异常处理为捕获的异常是每个应用程序具备的基本功能,C#在APPDomain提供了UnhandledException事件来接收未捕获到的异常的通知。常见的应用如下:staticvoidMain(string[]args){AppDomain.CurrentDomain.Unhand...

【转】编写高质量代码改善C#程序的157个建议——建议64:为循环增加Tester-Doer模式而不是将try-catch置于循环内

 建议64:为循环增加Tester-Doer模式而不是将try-catch置于循环内 如果需要在循环中引发异常,你需要特别注意,应为抛出异常是一个相当影响性能的过程。应该尽量在循环当中对异常发生的一些条件进行判断,然后根据条件进行处理。做个测试:Stopwatchwatch=Stopwatch.St...

【转】编写高质量代码改善C#程序的157个建议——建议63:避免“吃掉”异常

 建议63:避免“吃掉”异常嵌套异常是很危险的行为,一不小心就就会将异常堆栈信息,也就是真正的Bug出处隐藏起来。这还不是最严重的,最严重的就是“吃掉”异常,即捕获,然后不向上层throw。避免“吃掉”异常,并不是说不应该“吃...

【转】编写高质量代码改善C#程序的157个建议——建议62:避免嵌套异常

 建议62:避免嵌套异常应该允许异常在调用堆栈上往上传,不要过多的使用catch,然后再throw。过多的使用catch会带来两个问题:1)代码更多了。这看上去好像你根本不知道怎么处理异常,所以你总是不停地catch。2)隐藏了堆栈信息,使你不知道真正发生异常的地方。无故地嵌套是我们应该极力避免的。当然。如果...

【转】编写高质量代码改善C#程序的157个建议——建议61:避免在finally内撰写无效代码

 建议61:避免在finally内撰写无效代码在阐述建议之前,需要先提出一个问题:是否存在一种打破try-finally执行顺序的情况,答案是:不存在(除非应用程序本身因为某些很少出现的特殊情况在try块中退出)。应该始终认为finally内的代码会在方法return之前执行,哪怕return在try块中。正...

【转】编写高质量代码改善C#程序的157个建议——建议60:重新引发异常时使用Inner Exception

 建议60:重新引发异常时使用InnerException当捕获了某个异常,将其包装或重新引发异常的时候,如果其中包含了InnerException,则有助于程序员分析内部信息,方便代码调试。以一个分布式系统为例,在进行远程通信的时候,可能会发生的情况肯能会有:1)网卡被禁用或者网线断开,此时会抛出Socke...

【转】编写高质量代码改善C#程序的157个建议——建议59:不要在不恰当的场合下引发异常

 建议59:不要在不恰当的场合下引发异常常见的不易于引发异常的情况是对在可控范围内的输入和输出引发异常。privatevoidSaveUser3(Useruser){if(user.Age<0){thrownewArgumentOutOfRangeException("Age不能为负数。");}//保存...

【转】编写高质量代码改善C#程序的157个建议——建议58:用抛出异常代替返回错误代码

 建议58:用抛出异常代替返回错误代码CLR异常机制的优点:正常控制流会被立即中止,无效值或状态不会在系统中继续传播。提供了统一的处理错误的方法。提供了在构造函数、操作符重载及属性中报告异常的遍历机制。提供了异常堆栈,便于开发者定位异常发生的位置。不应该将异常机制用于正常控制流中,异常的发生是一个小概率事件,...

【转】编写高质量代码改善C#程序的157个建议——建议57:实现ISerializable的子类型应负责父类的序列化

 建议57:实现ISerializable的子类型应负责父类的序列化我们将要实现的继承自ISerializable的类型Employee有一个父类Person,假设Person没有实现序列化,而现在子类Employee却需要满足序列化的场景。不过序列化器并没有默认处理Person类型对象,这些事情只能由我们自...
首页上一页...135136137138139...下一页尾页