爲什麼Javadoc for java.util.Scanner不能描述它阻塞的條件？

爲java.util.Scanner筆記的Javadoc在於：爲什麼Javadoc for java.util.Scanner不能描述它阻塞的條件？

「這兩種hasNext和next方法可以阻塞等待進一步的輸入是否一個hasNext方法塊具有到其相關聯next方法是否會阻止無連接」。

在各has*和next*方法的描述，它也注意到，它們「在等待要掃描的輸入可能阻塞」。然而，儘管這些知識是使用這些方法的先決條件，但頁面並沒有提到這些方法可能阻止的條件。

因此，我的問題是，爲什麼Javadoc沒有描述掃描儀的方法可能會阻塞的條件？是否存在遺漏這些信息的正當理由，還是僅僅是文檔質量差的情況？

來源

2014-11-01 LogicChains

現在你已經提到它，它非常含糊。雖然，解釋它將意味着深入實施細節。

Scanner主要依賴於基礎流。 Scanner#next()將拋出一個NoSuchElementException每當底層流的read()方法在閱讀返回-1：

（執行概要）

public void next() { 
    if(needInput) 
     readInput(); 
    else 
     throwException(); 
} 

void readInput() { 
    int n = 0; 
    try { 
      n = underlyingStream.read(buf); 
    } catch (IOException ioe) { 
      lastException = ioe; 
      n = -1; //error happened 
    } 

    if (n == -1) 
      underlyingStreamClosed = true; 
} 

void throwException() { 
    if (underlyingStreamClosed) 
      throw new NoSuchElementException(); 
    else 
      throw new InputMismatchException(); 
}

例如，讓我們看看InputStream沒有掃描儀。 InputStream#read()塊時，它被稱爲，直到數據的用武之地。使用一個InputStream如System.in會導致您的Scanner阻止，因爲InputStream#read()塊（實現本機代碼編寫，所以如果你真的感興趣，你可以找到它位於的文件並自己查看implmenetation）。這適用於延伸InputStream的任何流，但不會覆蓋read()以更改其實施。例如，ObjectOutputStream,DataOutputStream

FileInputStream，但是，確實會覆蓋read()（也有本地實現）。調用FileInputStream#read()將返回-1當您嘗試閱讀，但沒有什麼（雖然文檔確實說這種方法可能會阻止，我還沒有碰到的情況下）。這純粹是由於你實際上不應該擔心的FileInputStream#read()的實現。

長話短說：它依賴於基礎流。熟悉你的流，你就會被設置。我看到它的方式，如果你真的擔心哪些數據流阻塞，看看實現（我發現當的子類不是覆蓋read()方法，他們傾向於阻止），自己測試它們，或看在線。文檔應該可能告訴你，雖然就像我說的，我還沒有碰到過FileInputStream#read()被阻止的時刻（有人可以幫助我重現這種情況，如果確實如文檔所述的那樣）

來源

2014-11-01 05:05:23

這是否意味着，如果從System.in讀取，'NoSuchElementException'永遠不會被拋出，就好像標準輸入是空的那麼掃描器將永遠阻塞？ – LogicChains 2014-11-01 05:32:43

我不完全確定你的意思。請詳細說明; 「*如果從System.in讀取，將永遠不會拋出異常*」令我困惑 – 2014-11-01 05:37:14

這應該是'NoSuchElementException永遠不會被拋出'。如果沒有更多的標記可用，Scanner.next（）會拋出一個NoSuchElementException異常，但是如果它阻塞，則意味着它會等待標記可用，因此不會拋出NoSuchElementException異常。 – LogicChains 2014-11-01 05:45:35

爲什麼Javadoc for java.util.Scanner不能描述它阻塞的條件？

回答

相關問題