尝试赶上不好的形式？ [英] try catch bad form?

问题描述

我想我有点知道这个问题的答案，但总有很多方法可以做的事情（其中有些是明显错误的:)）...

我有一个小递归函数找到一个员工经理的ID。这是在导入脚本中使用，这可能是人的直属经理已经离开（被禁用），所以我们需要找到员工（经理）经理（依此类推），因此我们可以将东西给他们。在情况下，它是不明显，EmployeesToDisable是如在此导入停用被标记雇员的通用列表。

我猜我真的要求是：是捕获异常太多了贸易往来关在这种情况下，使相关的开销。和我应该有不同的这样做。
这样做的工作很好，但感觉它是坏的形式。

我有code这样的：

 私人的Guid getMyEnabledManagersID（OnlineEmployee E）
    {
     员工管理;
     尝试
     {
      //看看员工E公司的经理是在伤兵名单。
      经理=（从EmployeesToDisable EMP那里emp.EmployeeID.Equals（e.ManagerID）选择EMP）。单（）;
      //是的，他们都是，所以需要再次调用此
      返回getMyEnabledManagersID（经理）;
     }
     抓住
     {
      返回e.ManagerID;
     }
    }
 

解决方案

撇开递归，你或许应该只使用的SingleOrDefault 和测试空。其实，你的可能的并不需要完整的员工对象 - 你可能只返回ID（境），即足以

 私人的Guid getMyEnabledManagersID（GUID经理ID）
{
    VAR禁用=（EMP从在EmployeesToDisable
                    其中，emp.EmployeeID ==经理ID
                    选择（GUID？）emp.ManagerID）.SingleOrDefault（）;
    返回禁用== NULL？经理ID：getMyEnabledManagersID（disabled.Value）;
}
 

其实，最大的关心我有原来的形式是，它不是特定于的键入的异常;它可能是线程中止，僵尸连接，僵局，等等。

i think i sort of know the answer to this, but there are always many ways to do things (some of which are clearly wrong :) )...

I have a little recursive function to find an employees manager's id. this is being used in a import script and it may be that the persons immediate manager has left (been disabled) so we need to find that employees (the manager) manager (and so on) so we can assign stuff to them. in case it isn't obvious, the EmployeesToDisable is a generic list of employees that are marked as disabled in this import.

I guess what i am really asking, is : is the overhead associated with catching an exception too much of a trade off to make in this instance. and should i be doing this differently. this does work fine, but feels like it is bad form..

i have code thus:

private Guid getMyEnabledManagersID(OnlineEmployee e)
    {
     Employee manager;
     try
     {
      //see if Employee e's manager is in the disabled list.
      manager = (from emp in EmployeesToDisable where emp.EmployeeID.Equals(e.ManagerID) select emp).Single();
      //yes they are, so need to call this again 
      return getMyEnabledManagersID(manager);
     }
     catch
     {
      return e.ManagerID;
     }
    }

解决方案

Leaving aside the recursion, you should perhaps just use SingleOrDefault and test for null. Actually, you probably don't need the full employee object - you can probably suffice with just returning the id (throughout), i.e.

private Guid getMyEnabledManagersID(Guid managerId)
{
    var disabled = (from emp in EmployeesToDisable 
                    where emp.EmployeeID == managerId
                    select (Guid?)emp.ManagerID).SingleOrDefault();
    return disabled == null ? managerId : getMyEnabledManagersID(disabled.Value);
}

Actually, the biggest concern I have with the original form is that it isn't specific to the type of exception; it could be "thread abort", "zombie connection", "deadlock", etc.

这篇关于尝试赶上不好的形式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！