2014-02-18 113 views
0

我正在做一個加密項目,我大部分都在工作。我正在從文件中讀取明文,並對其進行加密,然後將其寫入另一個文本文件。我有解密相同的東西。我有這個工作,但我有點困惑與讀取和寫入文件的嘗試和捕獲方法。我有兩種嘗試和捕獲方法,第二種嘗試方法不能識別我的「解密」變量。我應該如何處理這個問題?這裏是我的代碼:如何讓Java識別try塊內聲明的變量?

public static void decrypt(String pathname) 
{ 
    File file = new File(pathname); 
    Scanner input = null; 
    try 
    { 
    input = new Scanner(file); 
    String tempEncrypted = input.nextLine(); 
    StringBuffer encrypted = new StringBuffer(tempEncrypted); 

    StringBuffer decrypted = new StringBuffer(""); 
    int shiftAmount = (int)encrypted.charAt(0); 

    for(int i = 1; i < encrypted.length(); i++) 
    { 
     int decChar = ((int)encrypted.charAt(i) - shiftAmount); 
     while((int)decChar < 32) 
     { 
      decChar+=95; 
     } 
     decrypted.append((char)decChar); 
    } 
    } 
    catch(FileNotFoundException ex) 
    { 
    System.out.println("*** Cannot open " + pathname + " ***"); 
    System.exit(1); 
    } 
    try { 
    BufferedWriter out = new BufferedWriter(new FileWriter("decrypted.txt")); 
    for(int j = 0; j < decrypted.length(); j++) 
    { 
     out.write(decrypted.charAt(j)); 
    } 
    out.close(); 
    } 
    catch (IOException e) {} 


} 

謝謝和任何幫助,將不勝感激。

+0

我該如何解決這個問題呢?可以嘗試參數? – masonc15

+0

將變量聲明移至適當的範圍。 (「範圍」表示括住括號)。 –

+0

此外,它是一個try *塊*,而不是「嘗試方法」。 –

回答

0

如果一個變量在代碼塊中聲明,它的作用域僅限於該塊。您在try/catch塊內聲明decrypted,因此在塊之外,decrypted不再可用。你可以通過在try/catch塊前面移動decrypted聲明並只保留賦值來解決這個問題。

StringBuffer encrypted = new StringBuffer(); 
StringBuffer decrypted = new StringBuffer(); 

try { 
input = new Scanner(file); 
String tempEncrypted = input.nextLine(); 
encrypted = new StringBuffer(tempEncrypted); 
decrypted = new StringBuffer(""); 
int shiftAmount = (int)encrypted.charAt(0); 

... 
+0

這很有道理,但我希望在第一個try塊中發生的解密變化值在第二個try塊中可用。 – masonc15

+0

@ skateboard34:這段代碼如何表明在這裏不會是這種情況? –

+0

即使在try/catch塊之外聲明,這也不是問題,塊中的更改是通用的,因爲變量是由引用處理的。 – Warlord

1

decrypted變量不在第二個try的範圍內。爲了讓它在那裏可見,你可以聲明它並在第一個try塊之外初始化它,在那裏聲明你的Scanner對象和file

File file = new File(pathname); 
Scanner input = null; 
StringBuffer decrypted = new StringBuffer(""); 
... 
+1

在塊外聲明*並初始化*。 –

1

這是變量範圍的問題。第二個try/catch塊不知道第一個創建的變量。只要第一個try/catch塊完成,變量就會丟失。

如果您需要該變量在第二個變量中可見,則必須在第一次嘗試之前初始化該變量,然後在try塊中設置該值。那有意義嗎?

2

您錯過了try/catch塊的要點。如果拋出異常,則發生錯誤。 您不想從失敗的嘗試塊中檢索信息。

相反,只需要將你的try塊到一個try/catch語句如下:

public static void decrypt(String pathname) 
{ 
    File file = new File(pathname); 
    Scanner input = null; 
    try 
    { 
    input = new Scanner(file); 
    String tempEncrypted = input.nextLine(); 
    StringBuffer encrypted = new StringBuffer(tempEncrypted); 

    StringBuffer decrypted = new StringBuffer(""); 
    int shiftAmount = (int)encrypted.charAt(0); 

    for(int i = 1; i < encrypted.length(); i++) 
    { 
     int decChar = ((int)encrypted.charAt(i) - shiftAmount); 
     while((int)decChar < 32) 
     { 
      decChar+=95; 
     } 
     decrypted.append((char)decChar); 
    } 

    BufferedWriter out = new BufferedWriter(new FileWriter("decrypted.txt")); 
    for(int j = 0; j < decrypted.length(); j++) 
    { 
     out.write(decrypted.charAt(j)); 
    } 
    out.close(); 
    } 
    catch(FileNotFoundException ex) 
    { 
    System.out.println("*** Cannot open " + pathname + " ***"); 
    System.exit(1); 
    } 
    catch (IOException e) {} 

} 
+0

但是,如果有人希望在成功退出try塊後看到收集到的數據。 *在try塊內設置的所有*值以及希望在塊外部訪問的值必須在進入塊之前聲明*並初始化*。 –

+0

完全同意,+1 @HotLicks我建議'catch catch塊之後的代碼'本質上是一種反模式。有時可以這樣做,但它本質上是有問題的,應該以懷疑的態度來看待。 – EJP

+0

我同意你們兩方的意見,有時候這是適當的。但那些時間很少,而且這不是其中之一。 – gravityplanx

1

如果你有

void myMethod() { 
    try { 
     SomeClass x = someValue; 
    } 
    catch(..) {..} 

    SomeClass y = x; 
} 

編譯器將(理所當然)抱怨說,x未在規定因爲xtry{}括號內聲明,並且該聲明不能從定義的「範圍」中「逃避」 0。

如果不是有

void myMethod() { 
    SomeClass x; 
    try { 
     x = someValue; 
    } 
    catch(..) {..} 

    SomeClass y = x; 
} 

編譯器現在抱怨的x值不會在最後的賦值語句設定。這是因爲無法保證try範圍內的聲明已被執行。 (如果您將try替換爲if (some condition),並且在else支線中也沒有設置x,則同樣會生效。)

但如果你有

void myMethod() { 
    SomeClass x = null; 
    try { 
     x = someValue; 
    } 
    catch(..) {..} 

    SomeClass y = x; 
} 

編譯器會(合理的)幸福,因爲x是「看得見」在最後的賦值語句的範圍,它也被稱爲有賦值沿着從聲明點到使用地點的所有可能路徑。