2013-08-07 79 views
0

這是爲了檢查圖是兩方或不是代碼。我的問題是關於斷言。 我想檢查圖表是否爲null。即使在私有函數中,有效的java也鼓勵檢查。比方說,我添加一個斷言圖!= null,它將被檢查多次遞歸函數被調用。這看起來效率低下。如果如果遞歸函數之前完成檢查被調用,那麼我們違反有效的Java陳述最佳實踐,每一個功能應該驗證parameters.Is有一些最佳實踐/權衡等?謝謝。遞歸調用中的斷言?

private void dfsBipartiteDetector(Graph graph, int vertex, int i) { 
    assert graph != null; // <--------- appears inefficient for recursive call. 

    visited[vertex] = true; 

    vertexSets.get(i).add(vertex); 

    final List<Integer> adjList = graph.adj(vertex); 
    for (int v : adjList) { 
     if (!visited[v]) { 
      dfsBipartiteDetector(graph, v, i == 0 ? 1 : 0); 
     } else { 
      if (vertexSets.get(i).contains(v)) { 
       isBipartite = false; 
      } 
     } 
    } 
} 
+1

我不知道assert'的'的性能,但我有一個非常快的感覺。 – Augusto

+0

當沒有啓用斷言的情況下運行時,不應該有使用assert的任何可衡量的影響。然而,在這種情況下,無論如何你都會在這個方法中得到一個NPE(而不是在那個很難找到原因的地方)。 – Axel

回答

0

assert是不是默認。如果通過使用-ea選項啓動JVM來明確啓用該檢查,則該檢查僅實際運行。這個想法是在開發過程中啓用斷言,並在生產中禁用以解決您提到的折衷問題。

說了這麼多,我發現它有用有生產此類檢查,這就是爲什麼我喜歡用番石榴的的Preconditions代替assert關鍵字,因爲使用前檢查將始終運行。由於這種檢查造成的性能下降通常與代碼的其他部分相比可以忽略不計,並且它可以幫助調試難以調試的錯誤。

1

在調試專用代碼中的安全交易效率是一種很好的做法。

這是很常見的添加相當複雜只調試理智檢查代碼,檢查實例的整個數據結構的完整性。

只有在代碼減慢這麼多,它會擋住你的開發過程中的方式,你應該考慮一下減少這種檢查的量。