工程中實際問題解決兩例——基於C#
1. try catch的妙用
1.1 遇到問題的現象
機房動環監控系統，添加了100多個站點，新加設備無法同步，界面點同步，通信服務會報錯退出
同步設備操作如下：
通信異常如下：
大概意思是字典緩存中查無此值（根據鍵找）。
1.2 原因分析
其實每個比較大的bug都是系統設計不合理的地方，同時也是下次系統設計的寶貴經驗。
同時需要闡明的是bug只要能復現，就一定能解決，或者是從正面解決，或者是策略解決（受限於資源或者網絡的時候）。
主要從日志（文件打印或者命令窗口打印），數據庫，代碼三個層面。
1.2.1 先從數據庫入手
找到數據庫中歷史數據插入的表deviceData,會不會因為有些字段為非空了，導致插入失敗。全字段允許為空，結果依然報錯；
1.2.2 代碼日志逐級打印結合數據庫
根據窗體報錯的行數970，598，以及數據庫中的PesudoDevice表，結合系統設計的邏輯，大體流程如下：請求設備上報數據，根據協議設備將上報數據格式（配置規則），平台將協議模板序列化保存到PesudoDevice表的content字段中。采集的數據會按照告警規則與信號點規則，保存到businessSignal與activeAlarm表中去。
其中主要的兩個類型如下：
某機房的所有業務設備
/// <summary>
/// 業務設備模板內容
/// </summary>
public class PseudoDeviceTemplateContext
{
/// <summary>
/// 物理設備
/// </summary>
public List<string> ConcreteDeviceIDs { get; set; }
/// <summary>
/// 測點列表
/// </summary>
public List<PseudoDeviceTemplateSignal> Signals { get; set; }
}
單個信號點的類型
/// <summary>
/// 業務設備模板測點定義
/// </summary>
public class PseudoDeviceTemplateSignal
{
/// <summary>
/// 物理設備ID
/// </summary>
public string ConcreteDeviceID{get;set;}
/// <summary>
/// 物理設備名稱
/// </summary>
public string ConcreteDeviceName{get;set;}
/// <summary>
/// 物理設備類型ID
/// </summary>
public string ConcreteDeviceTypeID {get;set;}
/// <summary>
/// 物理設備類型ID
/// </summary>
public string ConcreteDeviceTypeName { get; set; }
/// <summary>
/// 測點ID
/// </summary>
public string SignalID { get; set; }
/// <summary>
/// 通道ID
/// </summary>
public string ChannelID { get; set; }
/// <summary>
/// 通道名稱
/// </summary>
public string ChannelName {get;set;}
/// <summary>
/// 通道類型
/// </summary>
public int? ChannelType {get;set;}
/// <summary>
/// 測點名稱
/// </summary>
public string SignalName{get;set;}
/// <summary>
/// 測點類型ID
/// </summary>
public string SignalTypeID{get;set;}
/// <summary>
/// 單位ID
/// </summary>
public string UnitMeasureID { get; set; }
/// <summary>
/// 告警條件列表
/// </summary>
public List<SignalAlarmCondition> AlarmConditions { get; set; }
/// <summary>
/// 存儲條件列表
/// </summary>
public List<DeviceDataStoreRule> DeviceDataStoreRules { get; set; }
/// <summary>
/// 精度
/// </summary>
public string MinPrecision { get; set; }
/// <summary>
/// 標稱值
/// </summary>
public double? Stander { get; set; }
/// <summary>
/// 標稱值
/// </summary>
public int? IsSaveHis { get; set; }
/// <summary>
/// 標稱值
/// </summary>
public double? MaxVal { get; set; }
/// <summary>
/// 標稱值
/// </summary>
public double? MinVal { get; set; }
/// <summary>
/// 標稱值
/// </summary>
public int? IsControl { get; set; }
/// <summary>
/// 標稱值
/// </summary>
public long? DataID { get; set; }
/// <summary>
/// 父數據ID
/// </summary>
public long? ParentDataID { get; set; }
}
1.2.3 原因分析
經過前端接口狀態查詢，數據庫sql查詢，日志逐級打印，最終定位某同步失敗站點數據表PesudoDevice的content字段為空，原來應該為設備ID集合與協議模板解析規則。因為該設備協議模板較大，而序列化json比較耗時，此時設備的輪詢報文到來，導致解析異常，從而程序崩潰。
1.2.4 解決方案
原因找准確了，解決方法其實很簡單，只要把一開始解析異常的代碼try catch異常。等解析規則存儲完畢了，自然就能把信號點解析准確。
異常崩潰代碼；
PseudoDeviceStatus data;
this.DPServiceObj.GetPseudoDeviceRealData(task.DstPseudoDeviceID, task.DstSignalID, out data );
解決異常代碼：
PseudoDeviceStatus data=null;
try
{
this.DPServiceObj.GetPseudoDeviceRealData(task.DstPseudoDeviceID, task.DstSignalID, out data);
}
catch (Exception e)
{
log.ErrorFormat("獲取設備實時數據失敗：{0}",e);
}
分析問題時間用了很久，對問題理解透徹了以后，解決問題並不需要幾行代碼。
1.2.5 問題解決
數據同步成功結果
2. json長度限制帶來的困惑
2.1 現象描述
隨着站點（含待測點）添加越來越多，單次加載遇到瓶頸，無法將全部數據單次加載。
2.2 問題分析
2.2.1 第一步，查看對應告警預案接口，報服務器錯誤
2.2.2 第二步，查看接口返回結果預覽
錯誤提示為返回字符串長度超過了json的默認最大長度，這個問題已經遇到過，設置下json序列化的最大長度即可輕松解決。
2.2.3 問題解決
問題代碼
/// <summary>
/// 獲取設備樹
/// </summary>
/// <returns></returns>
public ActionResult GetAlarmPlanDevTree()
{
List<object> children = new List<object>();
List<Area> areas = DevicesTreeHelper.GetAreaStation();
foreach (Area a in areas)
{
children.Add(GetATreeData(a, true));
}
return Json(children);
}
問題解決代碼
/// <summary>
/// 獲取設備樹
/// </summary>
/// <returns></returns>
public ActionResult GetAlarmPlanDevTree()
{
List<object> children = new List<object>();
List<Area> areas = DevicesTreeHelper.GetAreaStation();
foreach (Area a in areas)
{
children.Add(GetATreeData(a, true));
}
return new JsonResult() { Data = children, MaxJsonLength = int.MaxValue, ContentType = "application/json" };
}
解決之后所有測點信號加載成功
3. 小結
遇到問題並不可怕，只要能復現，根據具體提示，逐級打印日志，分析數據庫，問題就能迎刃而解，在此做個記錄，下次類似問題遇到能有印象，快速定位解決。
版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。