Groovy Exploration Closure II

Since programming into the object-oriented era, we have been working tirelessly with the process-oriented struggle. Think of all the patterns that we all love to use and serve as classic bang of four, and how much is for if ... else ... Such statements are optimized. But even if we do a lot of the above, some process-oriented language still stands there laughing at our incompetence.

A Solve the classic Try...catch problem

Yes, Try...catch is a classic problem we often encounter. Take a look at the following code:

publicstatic List getdatafromexcel (String filename,int beginrow,int endrow,modelintf model,string[] 　　　 Inputcols,list messages)
{
List retn = new ArrayList ();
InputStream fs = null;
Workbook WB =null; 　　　　　
Try
{
fs = new FileInputStream (fileName);
WB = Workbook.getworkbook (FS);
Sheet sh = wb.getsheet (0);
if (logger.isdebugenabled ()) {
Logger.debug ("sheetname =" + Sh.getname ());
}
int len = inputcols.length;
String[] values = new String[len];
.....
}
catch (Exception e)
{
if (logger.isdebugenabled ()) {
Logger.debug ("Excelre Ader ", e); 　　　
}
E.printstacktrace ();
　　　　　　　
finally
{
try {
if (fs!=null)
{
Fs.close ();
　　　　　　　
if (wb!=null)
{
Wb.close ()

} catch (IoexcePtion e) {
//TODO auto-generated catch block
E.printstacktrace ();

}
Return RETN
}

The code above is a piece of code that I read from an Excel document using the JXL API, and in order to focus on what we're talking about, I'm going to delete a section of the code. In this way, we can see clearly the try...catch statements in the code, and the role they play.

In my code for reading an Excel document, there are five or six similar methods. They all use such try...catch statements, and they do the same thing in the Catch statement segment and finally statement section, except that they do something different in the Try statement segment.

Do we all want to copy the same catch statement and finally sentence segments into each method? If you need to maintain a catch statement segment and a finally statement segment, do you want to modify each method?

See here, you must recall the use of the more classic JDBC API and come up with the classic spring solution to JDBC: JdbcTemplate.

Yes, the JdbcTemplate solution uses the Java inner class, which is a good solution and we feel pretty good with it. But, as I said earlier in the Groovy explorer closure, Java internal classes are rather obscure and cumbersome to use. See here, the Java fans do not rush to throw smelly eggs for me, look at closure solution first.