問題
最近遇到一個問題琳状，使用Java寫某個DSL標記語言X的parser（解析器）Maven插件的時候屉来，對外暴露一個名為Callback的接口和一個待實現(xiàn)的方法getHTML()——基于調(diào)用處傳入的文件名srcX構(gòu)造出HTML文件的輸出路徑（其實此處的Callback就是一個閉包走越，文件名是一個自由變量）浩淘。大致代碼如下：
parser.parse(srcX, new Callback() {
@Override
public FileWriter getHTML() {
return new FileWriter(outputPath(suffix(srcX, "html")));
}
});
private String suffix(String filename, String suffix) {
return Joiner.on(".").join(filename, suffix);
}
//這里假設(shè)輸入和輸出根路徑地址已知
private File outputPath(String file) {
return new File(
file.replace(srcDir.getAbsolutePath(), //srcDir: File
outputDir.getAbsolutePath())); //outputDir: File
}
目前為止還沒有任何問題痘绎。但若是運行時，這段程序很可能拋出異常java.io.FileNotFoundException: your-file-name (No such file or directory)蛉幸。原因在于file的路徑當(dāng)中可能存在多級父級目錄破讨，例如：outputDir/p1/p2/srcX.html，那么當(dāng)FileWriter嘗試創(chuàng)建srcX.html就會失敗奕纫。此時最簡單的方法就是提前創(chuàng)建好所有的父級目錄提陶，于是outputPath()方法會變成下面這樣：
private File outputPath(String file) {
File outputFile = new File(
file.replace(srcDir.getAbsolutePath(),
outputDir.getAbsolutePath()));
outputFile.getParentFile().mkdirs(); //創(chuàng)建可能不存在的父級目錄
return outputFile;
}
似乎這段程序可以正常工作了，但是創(chuàng)建文件夾這樣的操作是可能失敗的匹层。所以我們需要關(guān)注是否創(chuàng)建成功隙笆，若失敗，則寫入Log文件當(dāng)中升筏。修改程序如下：
private File outputPath(String file) {
File outputFile = new File(
file.replace(srcDir.getAbsolutePath(),
outputDir.getAbsolutePath()));
final File parentDirs = outputFile.getParentFile();
if (!parentDirs.exists()) {
if (!parentDirs.mkdirs()) {//創(chuàng)建可能不存在的父級目錄
getLog().error("Cannot create parent dirs for {}", outputFile);
}
}
return outputFile;
}
注意
這里我們需要先判斷父級目錄是否存在撑柔，即parentDirs.exists()？可是parentDirs.mkdirs()不是直接返回boolean值來表示是否創(chuàng)建成功嗎您访？是這樣么铅忿？這兒有mkdirs()方法的說明：
public boolean mkdirs()
Creates the directory named by this abstract pathname, including any necessary but nonexistent parent directories. Note that if this operation fails it may have succeeded in creating some of the necessary parent directories.
Returns:
true if and only if the directory was created, along with all necessary parent directories; false otherwise
也就是說只有當(dāng)這個目錄及其所有的父級目錄都被創(chuàng)建時，才返回true灵汪，反之返回false檀训。照這個推論，如果所有目錄事先已經(jīng)存在了享言，這個方法應(yīng)該也會返回true峻凫，畢竟都被創(chuàng)建過了嘛。但是只要稍微看一眼源碼担锤，你就會發(fā)現(xiàn)事實并非如此：
//mkdirs源碼
if (exists()) {
return false;
}
所以這里需要特別強調(diào)was created是一種操作蔚晨，如果沒有進行這個操作，那就不能算這個方法成功肛循。
前面已經(jīng)提到過，我需要寫一個maven的插件银择，所以最好在這種導(dǎo)致程序崩潰的地方拋出一個maven中通用的異常MojoExecutionException多糠。這樣，更改代碼如下：
private File outputPath(String file) {
File outputFile = new File(
file.replace(srcDir.getAbsolutePath(),
outputDir.getAbsolutePath()));
final File parentDirs = outputFile.getParentFile();
if (!parentDirs.exists()) {
if (!parentDirs.mkdirs()) {//創(chuàng)建可能不存在的父級目錄
getLog().error("Cannot create parent dirs for {}", outputFile);
throw new MojoExecutionException("Cannot create parent dirs");
}
}
return outputFile;
}
此時浩考，問題才顯出端倪——異常MojoExecutionException是一個受檢的異常(checked Exception)夹孔，它間接繼承自java.lang.Exception。可是我們的getHTML()方法并沒有在簽名中拋出任何異常搭伤，編譯無法通過只怎。那唯一的辦法就是try...catch了，但是我不應(yīng)該捕獲自己剛剛拋出來的異常怜俐，否則拋出受檢異常的意義何在身堡？
這時，自然而然會想到拍鲤，將方法簽名改成getHTML() throws MojoExecutionException贴谎。確實可行，但是并不合適季稳，因為MojoExecutionException只是Maven插件規(guī)定的異常擅这，而getHTML()則是一個對外暴露的API，不應(yīng)該依賴于某個具體的異常景鼠。所以我將異常擴大化：getHTML() throws Exception仲翎，這樣做的好處很明顯，壞處也很顯眼铛漓。
好處
- 牢記《Unix編程藝術(shù)》中的“寬收嚴發(fā)”原則溯香。即子類實現(xiàn)父類、接口的方法票渠，入?yún)⒖梢詳U大逐哈，出參可以縮小。舉個例子：父類问顷、接口有個方法
public Object something(HashMap map) throws Exception
那么子類實現(xiàn)這個方法可以這樣寫
public String something(Map map)
throws ExecutionException, NoSuchMethodException
這里昂秃，入?yún)⑹荋ashMap，出參是Object和Exception杜窄。入?yún)U大肠骆，所以子類出現(xiàn)了Map；出參縮小塞耕，所以子類出現(xiàn)了String和ExecutionException和NoSuchMethodException蚀腿。同理，此處getHTML() throws Exception由子類實現(xiàn)的形式可以是getHTML() throws MojoExecutionException扫外。
壞處
- 不管getHTML()是否需要拋出異常莉钙，你都得在實現(xiàn)代碼中拋出異常；
- 由于對外表現(xiàn)的是拋出較寬泛的Exception筛谚，所以喪失了對于具體受檢 (checked exception)異常進行檢查的好處磁玉。
這里有個JDK中比較類似的例子，就是關(guān)于Runnable和Callable接口的設(shè)計問題：
public interface Runnable {
public void run();
}
public interface Callable<V> {
V call() throws Exception;
}
它們就是兩個極端驾讲，Runnable必須將受檢的異常轉(zhuǎn)換成非受檢(unchecked exception)或者發(fā)明一種方式來將異常暴露給調(diào)用者蚊伞；Callable就是無論如何都得拋出異常席赂，而且迫使用戶去捕獲一個較寬泛的異常。
解決方式
這個時候时迫，泛型就派上用場了颅停。
interface Callback<E extends Exception> {
FileWriter getHTML() throws E;
}
//interface parser
public <E extends Exception> void parse(String srcX, Callback<E> cb) throws E;
通過這種方式，我們可以捕獲具體的異常：
try {
parser.parse(srcX, new Callback<MojoExecutionException>() {
@Override
public FileWriter getHTML() throws MojoExecutionException {
return new FileWriter(outputPath(suffix(srcX, "html")));
}
});
} catch (MojoExecutionException e) {
getLog().error("Failed to execute. {}", e);
}
使用lambda表達式可以簡化成下面的模樣：
try {
parser.parse(srcX, (Callback<MojoExecutionException>) () -> new FileWriter(outputPath(suffix(srcX, "html"))));
} catch (MojoExecutionException e) {
getLog().error("Failed to execute. {}", e);
}
我們解決了迫使用戶去捕獲一個較寬泛的異常的問題掠拳，但是無論如何都得拋出異常這個問題還是沒有得到解決癞揉。或許我們需要一個像是throws Nothing一樣的語法碳想，表示什么也沒有拋出來烧董。我們知道RuntimeException是非受檢的異常(unchecked exception)，所以throws RuntimeException就表明這個異常跟沒有拋出異常一樣胧奔，不需要捕獲逊移。如下：
parser.parse(srcX, new Callback<Nothing>() {
@Override
public FileWriter getHTML() throws Nothing {
return new FileWriter(outputPath(suffix(srcX, "html")));
}
});
public abstract class Nothing extends RuntimeException {}
走到這一步，我們算是較為完全地解決了匿名內(nèi)部類的異常處理問題龙填。
異常透明化
With the throws type parameter on the Block interface, we can now accurately generify over the set of exceptions thrown by the Block; with the generic forEach method, we can mirror the exception behavior of the block in forEach(). This is called exception transparency because now the exception behavior of forEach can match the exception behavior of its block argument. Exception transparency simplifies the construction of library classes that implement idioms like internal iteration of data structures, because it is common that methods that accept function-valued arguments will invoke those functions, meaning that the library method will throw a superset of the exceptions thrown by its function-valued arguments.
interface Block<T, throws E> {
public void invoke(T element) throws E;
}
interface NewCollection<T> {
public<throws E> forEach(Block<T, throws E> block) throws E;
}
異常透明化胳泉，簡單來講，就是調(diào)用者的簽名中的異常完全由它的函數(shù)值(function-valued)的參數(shù)決定岩遗，所有這些調(diào)用者最終的異常都會是該函數(shù)值所注異常的超集扇商。
異常透明化就是用來解決我們常用的通過內(nèi)部類模擬閉包調(diào)用時異常處理的手法了。
閉包的定義
一個包含了自由變量的開發(fā)表達式宿礁，和該自由變量的約束環(huán)境組合之后案铺，產(chǎn)生了一種封閉的狀態(tài)。
參考鏈接
[1] Exception Transparency
[2] Throwing Checked Exceptions from Anonymous Inner Classes
