作者abc95007 (別理我)
看板C_Sharp
標題[問題] 防呆寫法
時間Thu Oct 4 15:10:07 2018
請問關於 C# 防呆 寫法要怎樣比較妥當?
下面四種方法
Funciton 回傳 bool , 最外層再來寫錯誤訊息
或是 string 或 enum 或是自己些個 關於 Error class 代進去
或是 try catch (應該比較不推薦)
寫法讓我困擾滿久的
感謝~
public enum Error
{
Pass, CantOpenFile,
}
class Program
{
static void Main(string[] args)
{
string filePath = @"C:\123.txt";
//case1
//用 if + bool 來判斷是否成功 ,
if (File.checkFile(filePath))
{
Console.WriteLine("檔案存在");
}
else
{
Console.WriteLine("檔案不存在");
}
//case2
// 用 message 丟進去, 再判斷是否成功 , 無回傳 bool
string message = "";
File.checkFile(filePath, ref message);
Console.WriteLine(message);
//case3
Error error = Error.Pass;
File.checkFile(filePath, ref error);
Console.WriteLine(error.ToString());
//case4
try
{
//........
}
catch (Exception)
{
throw;
}
}
}
class File
{
public static bool checkFile(string filePath)
{
bool result = System.IO.File.Exists(filePath);
return result;
}
public static void checkFile(string filePath, ref string message)
{
if(System.IO.File.Exists(filePath))
{
message = "檔案存在";
}
else
{
message = "檔案不存在";
}
}
public static void checkFile(string filePath, ref Error error)
{
if (System.IO.File.Exists(filePath))
{
error = Error.Pass;
}
else
{
error = Error.CantOpenFile;
}
}
}
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 42.73.155.188
※ 文章網址: https://webptt.com/m.aspx?n=bbs/C_Sharp/M.1538637010.A.F0C.html
1F:推 lightyen: 日防夜放家賊難防 用OpenFileDialog 10/04 16:07
2F:推 jass970991: 同意樓上 但如果硬要挑一種寫法出來 我會直接丟except 10/04 16:29
3F:→ jass970991: ion 外面接的人要去負責處理 文件寫清楚就好 10/04 16:29
我自己來自問自答好了
開檔寫入只是想舉例而已
只是想知道class 裡面到底哪一步有問題, 可以傳到最外層讓UI顯示
與同事討論過後 應該比較像下列
丟出個 Error,再讓外面去顯示
不知道是否有更好建議
public static class Error
{
public static int PASS = 0;
public static int OPEN_FILE = 1;
public static int WRITE_FILE = 2;
}
class File
{
string path = @"C:\\";
public static int openAndWriteFile(string path)
{
if(!File.openFile(path))
return Error.OPEN_FILE;
if (!File.writeString("hello"))
return Error.WRITE_FILE;
return Error.PASS;
}
public static bool openFile(string File)
{
return true;
}
public static bool writeString(string str)
{
return true;
}
}
※ 編輯: abc95007 (220.133.187.22), 10/04/2018 23:03:07
4F:推 jass970991: 我經驗沒有很多 不過我有點好奇 你願意自己寫一個clas 10/04 23:35
5F:→ jass970991: s而不願意使用exception去接的原因是什麼 try catch 10/04 23:35
6F:→ jass970991: 本身也可以接各種不同的exception 單純好奇理由 想 10/04 23:35
7F:→ jass970991: 學習各種不同的思維模式 10/04 23:35
也是從別人那邊 code 學來的
try 似乎比較像是在無法預期會發生什麼錯誤
比較難掌控情況下使用
function 丟出個 bool 出來, 再去判斷
檔案開啟失敗了, 我就知道 Error 是甚麼
檔案寫入失敗了,我就知道 Error 是甚麼
但我還是不太確定對於防呆哪一種比較好, 同時又讓外面 UI 知道到底錯在哪裡
※ 編輯: abc95007 (220.133.187.22), 10/05/2018 00:05:46
8F:推 CloudyWing: 一般來說取決於層級,較底層的是例外,較外層是bool o 10/05 02:36
9F:→ CloudyWing: r message 10/05 02:36
10F:→ CloudyWing: 舉例來說操作介面來的資料是允許對方可能會輸入錯誤, 10/05 02:41
11F:→ CloudyWing: 就不該用例外處理,而是判斷完值後回傳訊息,但較底層 10/05 02:41
12F:→ CloudyWing: 的api則是直接預期對方使用這個api應該要知道適當參數 10/05 02:41
13F:→ CloudyWing: 為何,當不符合則是拋出例外。 10/05 02:41
14F:→ CloudyWing: 簡單來說還是取決於你對函式的定位,假設你的案例程式 10/05 02:45
15F:→ CloudyWing: 是在Main呼叫函式,我傾向於不用例外 10/05 02:45
16F:推 CloudyWing: 然後訊息方式enum or bool+out message or 寫一個資料 10/05 02:50
17F:→ CloudyWing: 結構(structure和class都行)封裝是否成功和訊息都可以 10/05 02:50
18F:→ CloudyWing: ,用哪種也是看需求 10/05 02:50
19F:→ CloudyWing: 如果會需要判斷回傳訊息是哪種而執行不同行為用enum; 10/05 02:55
20F:→ CloudyWing: 想要知道有沒有成功並且show訊息用第二種;第三種就比 10/05 02:55
21F:→ CloudyWing: 較彈性,你可以同時封裝bool messsge enum,然後看情 10/05 02:55
22F:→ CloudyWing: 況決定 10/05 02:55
23F:→ CloudyWing: 話說你的message應該用out不是ref,用ref會讓人預期是 10/05 02:57
24F:→ CloudyWing: 訊息的累加 10/05 02:57
25F:推 DeathTemp: try catch不是用來處理無法預期的錯誤的,MSDN有說明 10/05 19:57
27F:→ DeathTemp: 觀念,我還看過有人把每一個function的內容都用try包起 10/05 20:00
28F:→ DeathTemp: 來,每一個喔,更扯的是他的catch裡面什麼都沒做,等於 10/05 20:00
29F:→ DeathTemp: 出現exception時完全沒有訊息,使用者連反映都沒機會 10/05 20:01
30F:→ DeathTemp: 如果懷疑自己寫的程式可能會有自己無法預期的錯誤,你 10/05 20:03
31F:→ DeathTemp: 要做的事應該是debug或把錯誤變成可以預期的,而不是放 10/05 20:04
32F:→ DeathTemp: 著不管,用try包起來就了事 10/05 20:05
33F:→ DeathTemp: 把一支「我不知道他有沒有bug,也不知道哪裡會有bug」 10/05 20:06
34F:→ DeathTemp: 的程式交出去不覺得怪怪的嗎? 10/05 20:06
35F:→ kobe8112: 例外不是都有名稱嗎...你看官方的各種函式,如果會跳例 10/05 21:36
36F:→ kobe8112: 外,每種不同的例外在什麼情況會跳出來不是都有說明嗎? 10/05 21:37
37F:→ kobe8112: 怎麼會不知道Error是什麼呢? 10/05 21:37
38F:→ feeya: log(e.message) 印出來你就知道是哪個exception 10/06 00:27
39F:推 t64141: 很多工程師都把catch地毯式使用,每次看到都覺得很吐血 10/06 00:45
40F:→ t64141: 曾經有同事說: 預防萬一,所以每個方法都要try-catch 10/06 00:48
41F:推 CloudyWing: 全包try catch和throw ex真的是try catch兩大誤用 10/06 00:51
42F:→ t64141: throw ex 也是經典,看過一個專案到處throw ex,然後同事 10/06 00:58
43F:→ t64141: 看到stack trace之後認為是try-catch不夠,於是下一層的 10/06 00:58
44F:→ t64141: 方法也都加了try-catch,印完log再重拋出去外面再印一次, 10/06 00:58
45F:→ t64141: 很恐怖XD 10/06 00:58
46F:推 chentsungmin: 建議try catch原則,能處理或需處理才去 catch, 另 10/06 06:16
47F:→ chentsungmin: 外 catch 可以寫多段,針對不同型別的exception,這 10/06 06:16
48F:→ chentsungmin: 也可以達到你依不同的 error,丟出不同的exception, 10/06 06:16
49F:→ chentsungmin: 裡面可以附加更多不同資訊,而不是一個整數或列舉 10/06 06:16
50F:→ chentsungmin: 的限制,它有效能的消耗 10/06 06:16
51F:→ jim7434: try catch 跟 bool 應付的是不同層級的錯誤處理 10/06 11:05
52F:推 dontblame: try catch 才是好方法,只是要將清楚資訊 丟給呼叫者 10/09 17:04
53F:→ s9041200: 丟出有意義的例外,catch有意義的例外再針對每個case處 11/02 21:54
54F:→ s9041200: 理 11/02 21:54