1.  一般如你一样都是在在Global.asax的   protected void Application_Error(object sender, EventArgs e)中捕获
和写进日志
2.  这是asp.net的机制，你可以在页面设置 不开启保护
3. 不推荐 自定义异常

1. 只要是调到错误页，在page类里边捕获 Page_OnError事件，或者全局捕获，或者仅仅在 config 文件中设置一下，都是可以的。不过在调试时，应该去掉它，让错误以尽可能详细、技术化页面（黄页）显示出来，而不要使用自定义错误页。实际上许多网站特意发布debug版到生产环境服务器上去，如果网站出错，就会立刻显示详细信息，方便开发人员快速诊断问题。
2. 这通常都是因为一些网页使用普通的 application/x-www-form-urlencoded 来提交那种数据，而没有使用专用的形式。这种普通的形式，被直接用于网页普通“文本输入”来使用，因此 asp.net 做了一个限制。按理说所谓的“html编辑器”之类的特殊程序，应该使用特殊的（例如）ajax（通过json）等特殊方式提交数据才对。你应该看看你使用的第三方组件是不是这样。目前似乎只是因为“html编辑器”比较滥，才会让asp.net程序检查出这个问题来。所以没有必要为了用这种编辑器，去修改asp.net安全机制。
3. 自己的程序当然要经常抛出异常的！比如说我们的程序处理用户消费时，可能写

if( 余额 < 消费金额)
    throw new Exception(string.Format("余额只有{0}元了，无法购买别墅，请赶紧充值。", 余额)); 

这里是抛出一个普通的异常，要抛出强类型的异常，自然就稍微复杂一点封装一个自定义异常。
你所谓的“让其捕捉做特定的事情”，是有点“杞人忧天”的。既然.net类库可以抛出它自定义的几百种异常来，我们的应用程序自然也可以抛出我们自定义的十几种自定义异常来。应用程序处理异常的原则（例如你的问题1.）都是一样的。你在设计自定义异常类型时，不用去担忧如何处理的问题。不要纠结如何处理的问题。
你的程序自己去主动抛出异常，这应该是常常干的事情。就上这个“余额<消费金额”的例子一样！

对于一些人来说，可能是因为仅仅做过一点“皮毛的”界面小程序的原因，可能觉得遇到业务逻辑判断异常，只要给个“模态对话框”就行了。以为自定义异常都是“纯技术”的，因为.net类库抛出的异常好像都是纯技术的而非业务的一样。
.net类库基本上没有业务框架、只有技术框架，因此它自然不会抛出业务异常来。但是.net异常处理框架是通用的！你要是做一个业务模块并且是作为服务被其它各种模块（包括不是当前解决方案的其它项目去引用），但是它自己不处理最终表现层，那么它就应该抛出自定义的异常，走.net的异常处理机制来通知上层调用程序捕获异常。这是规范做法。而那种使用函数返回一个小于0的int整数的做法是20年前的c程序的做法，这不受高级的应用异常捕获机制、开发工具调试机制的支持。