Java 8 - effectively final variables, lambdas and try/catch/finally block - java

So I've started playing with Java 8 streams/lambda expressions and have encountered and interesting issue that I'm not really sure how to resolve. So here I am, asking you for help.
Sample code in question:
public void insertBlankPages(File inputFile, String outputFile, final int OFFSET) {
PDDocument newDocument;
PDDocument oldDocument;
try {
newDocument = createNewDocument();
oldDocument = createOldDocument(inputFile);
List<PDPage> oldPages = getAllPages(oldDocument);
oldPages.stream()
.limit(oldPages.size() - OFFSET)
.forEach(page -> {
newDocument.addPage(page);
newDocument.addPage(new PDPage(page.getMediaBox()));
});
newDocument.save(outputFile);
} catch (IOException e) {
e.printStackTrace();
} catch (COSVisitorException e) {
e.printStackTrace();
} finally {
newDocument.close();
oldDocument.close();
}
}
With the code above, compiler complains about the call to close() in the finally block. The error is: "Variable newDocument might not have been initialized". Same for oldDocument.
Naturally, I go ahead and initialize the variables as follow:
PDDocument newDocument = null;
PDDocument oldDocument = null;
Now I get compiler error "Variable used in lambda expression should be effectively final".
How to go about this?
Methods createNewDocument and createOldDocument throw an exception, so the calls must be within try/catch block. I also need to close the documents within the finally block.
I should be able to work around this issue by using try-with-resources. But, I'm curious to hear if there's any other proper solution for this.
Thanks.

The proper solution is try-with-resources.
Without that, you'd need to manually nest some more try/finally blocks:
try {
PDDocument newDocument = createNewDocument();
try{
PDDocument oldDocument = createOldDocument(inputFile);
try{
// .....
}
finally { oldDocument.close() }
}
finally{ newDocument.close(); }
}
catch (IOException e) {
e.printStackTrace();
}

Thanks everyone for the ideas. It appears that there isn't a "good" way of doing this without try-with-resources. Here is an example using try-with-resources.
public void insertBlankPages(File inputFile, String outputFile, final int OFFSET) {
try (PDDocument newDocument = createNewDocument();
PDDocument oldDocument = createOldDocument(inputFile)) {
List<PDPage> oldPages = getAllPages(oldDocument);
oldPages.stream()
.limit(oldPages.size() - OFFSET)
.forEach(page -> {
newDocument.addPage(page);
newDocument.addPage(new PDPage(page.getMediaBox()));
});
newDocument.save(outputFile);
} catch (IOException e) {
e.printStackTrace();
} catch (COSVisitorException e) {
e.printStackTrace();
}
}

Simple work-around is to use an array, which itself is final so you can reference it in a lambda, but its contents are free to change.
This code is essentially the same as your, but has no compile errors:
public void insertBlankPages(File inputFile, String outputFile, final int OFFSET) {
PDDocument[] newDocument = new PDDocument[1]; // automatically filled with a null
PDDocument oldDocument = null;
try {
newDocument[0] = createNewDocument();
oldDocument = createOldDocument(inputFile);
List<PDPage> oldPages = getAllPages(oldDocument);
oldPages.stream()
.limit(oldPages.size() - OFFSET)
.forEach(page -> {
newDocument[0].addPage(page);
newDocument[0].addPage(new PDPage(page.getMediaBox()));
});
newDocument[0].save(outputFile);
} catch (IOException e) {
e.printStackTrace();
} catch (COSVisitorException e) {
e.printStackTrace();
} finally {
if (newDocument[0] != null)
newDocument[0].close();
if (oldDocument != null)
oldDocument.close();
}
}

Related

java itext catching null exception pdf text extraction

When extracting text form pdf using itext 5.3.4 using this code:
try {
reader = new PdfReader(thepdffilename);
} catch (IOException e) {
openok=false;
}
if (openok==true){
int numberOfPages = reader.getNumberOfPages();
PdfReaderContentParser parser = new PdfReaderContentParser(reader);
for (int page = 1; page <= numberOfPages; page++){
try {
SimpleTextExtractionStrategy strategy = parser.processContent(page, new SimpleTextExtractionStrategy());
content = content + strategy.getResultantText();
} catch (Throwable t) {
crap=true;
break;
}
}
reader.close();
}
However occasionally GooglePlay crashes & ANRs reports that there has been a NP exception in itext.
java.lang.NullPointerException in com.itextpdf.text.pdf.PdfReader$PageRefs.readPages at
com.itextpdf.text.pdf.PdfReader$PageRefs.readPages(PdfReader.java:3382) at
com.itextpdf.text.pdf.PdfReader$PageRefs.<init>(PdfReader.java:3350) at com.itextpdf.text.pdf.PdfReader$PageRefs.<init>(PdfReader.java:3328) at
com.itextpdf.text.pdf.PdfReader.readPages(PdfReader.java:1003) at com.itextpdf.text.pdf.PdfReader.readPdf(PdfReader.java:530) at
com.itextpdf.text.pdf.PdfReader.<init>(PdfReader.java:170) at
com.itextpdf.text.pdf.PdfReader.<init>(PdfReader.java:159)
The 5.3.4 source code at line 3382 is:
http://grepcode.com/file/repo1.maven.org/maven2/com.itextpdf/itextpdf/5.3.4/com/itextpdf/text/pdf/PdfReader.java?av=f
3374 void readPages() throws IOException {
3375 if (refsn != null)
3376 return;
3377 refsp = null;
3378 refsn = new ArrayList<PRIndirectReference>();
3379 pageInh = new ArrayList<PdfDictionary>();
3380 iteratePages((PRIndirectReference)reader.catalog.get(PdfName.PAGES));
3381 pageInh = null;
3382 reader.rootPages.put(PdfName.COUNT, new PdfNumber(refsn.size()));
3383 }
3384
3385 void reReadPages() throws IOException {
3386 refsn = null;
3387 readPages();
3388 }
So something is going wrong when certain pdf files are having their text extracted and the reason why that could be happening is probably never going to be sorted as I do not have the pdfs in question.
What I require is a method of catching the NP exception so my app does not crash.
I've tried
} catch (Exception e) {
and as a last resort to try and catch any exception
} catch (Throwable t) {
Does anyone have an idea how I can get this particular itext error to be caught?
thanks
If I understand you correctly, your attempts to catch that NPE have been made in your loop through the document pages:
for (int page = 1; page <= numberOfPages; page++){
try {
SimpleTextExtractionStrategy strategy =
parser.processContent(page, new SimpleTextExtractionStrategy());
content = content + strategy.getResultantText();
} catch (Throwable t) {
crap=true;
break;
}
}
If you look closely at your Exception, though...
java.lang.NullPointerException in com.itextpdf.text.pdf.PdfReader$PageRefs.readPages at
com.itextpdf.text.pdf.PdfReader$PageRefs.readPages(PdfReader.java:3382) at
[...]
com.itextpdf.text.pdf.PdfReader.<init>(PdfReader.java:159)
you see that the exception already occurs in the PdfReader construction (PdfReader.<init>). Thus, you have to catch the NPE already where you construct your PdfReader:
try {
reader = new PdfReader(thepdffilename);
} catch (IOException e) {
openok=false;
} catch (NullPointerException npe) { // !!
openok=false; // !!
}
Or if you want to take no chances
try {
reader = new PdfReader(thepdffilename);
} catch (Throwable t) { // !!
openok=false;
}
If you have other code locations, too, in which a PdfReader is constructed, you may want to harden them, too.
#BrunoLowagie This NPE had better be transformed to a tagged exeption, hadn't it?
This is ugly but if you really want to catch it , try and catch RuntimeException

Return in a 'finally' statement

I'm trying to read ObjectOutputStream from a file and convert it to an arraylist.
This whole thing is happening inside a method which should read the file and return the array list:
public static List<Building> readFromDatabase(){
String fileName="database.txt";
FileInputStream fileIStream=null;
ObjectInputStream in=null;
List<Building> buildingsArr=null;
try
{
fileIStream = new FileInputStream(fileName);
in = new ObjectInputStream(fileIStream);
buildingsArr=(ArrayList<Building>)in.readObject();
}
catch(IOException e)
{
e.printStackTrace();
}
catch(ClassNotFoundException e)
{
Console.printPrompt("ArrayList<Building> class not found.");
e.printStackTrace();
}
finally{
Console.printPrompt("Closing file...");
close(in);
close(fileIStream);
return buildingsArr;
}
}
Java tells me that this is dangerous.
What are the alternatives?
I can't put the return in the "try" block because it won't do it / it won't close files in the "finally" block.
I need to both make sure files will be closed, and return the array list I created as well.
Any ideas?
I can't put the return in the "try" block because it won't do it / it
won't close files in the "finally" block.
Wrong, finally block would still execute if you put return in try block. Thus you can return in your try block.
try
{
//your code
return buildingsArr;
}
catch(IOException e)
{
e.printStackTrace();
}
catch(ClassNotFoundException e)
{
Console.printPrompt("ArrayList<Building> class not found.");
e.printStackTrace();
}
finally{
Console.printPrompt("Closing file...");
close(in);
close(fileIStream);
}
I would suggest starting to use Java 7, and the try with resources clause. http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
Ex:
static String readFirstLineFromFile(String path) throws IOException {
try (BufferedReader br = new BufferedReader(new FileReader(path))) {
return br.readLine();
}
}
You must either throw an Exception or return a value:
All you need to prove this is comment out the return "File Not Found" after the finally block and see that it won't compile.
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
public class ReturnFinallyExample
{
public static void main(final String[] args)
{
returnFinally();
}
private static String returnFinally()
{
try
{
final File f = new File("that_does_not_exist!");
final FileInputStream fis = new FileInputStream(f);
return "File Found!";
}
catch (FileNotFoundException e)
{
e.printStackTrace();
}
finally
{
System.out.println("finally!");
}
return "File Not Found!";
}
}
You must have the return after the finally or you have to either:
declare the method to throws FileNotFoundExceptoin and re-throw the FileNotException out.
or
wrap the FileNotFoundException with throw new RuntimeException(e)

Eclipse Juno : unassigned closeable value

I am wondering why I get this warning with the new eclipse Juno despite I think I correctly closed everything. Could you please tell me why I get this warning in the following piece of code?
public static boolean copyFile(String fileSource, String fileDestination)
{
try
{
// Create channel on the source (the line below generates a warning unassigned closeable value)
FileChannel srcChannel = new FileInputStream(fileSource).getChannel();
// Create channel on the destination (the line below generates a warning unassigned closeable value)
FileChannel dstChannel = new FileOutputStream(fileDestination).getChannel();
// Copy file contents from source to destination
dstChannel.transferFrom(srcChannel, 0, srcChannel.size());
// Close the channels
srcChannel.close();
dstChannel.close();
return true;
}
catch (IOException e)
{
return false;
}
}
IF you're running on Java 7, you can use the new try-with-resources blocks like so, and your streams will be automatically closed:
public static boolean copyFile(String fileSource, String fileDestination)
{
try(
FileInputStream srcStream = new FileInputStream(fileSource);
FileOutputStream dstStream = new FileOutputStream(fileDestination) )
{
dstStream.getChannel().transferFrom(srcStream.getChannel(), 0, srcStream.getChannel().size());
return true;
}
catch (IOException e)
{
return false;
}
}
You won't need to explicitly close the underlying channels. However if you're not using Java 7, you should write the code in a cumbersome old way, with finally blocks:
public static boolean copyFile(String fileSource, String fileDestination)
{
FileInputStream srcStream=null;
FileOutputStream dstStream=null;
try {
srcStream = new FileInputStream(fileSource);
dstStream = new FileOutputStream(fileDestination)
dstStream.getChannel().transferFrom(srcStream.getChannel(), 0, srcStream.getChannel().size());
return true;
}
catch (IOException e)
{
return false;
} finally {
try { srcStream.close(); } catch (Exception e) {}
try { dstStream.close(); } catch (Exception e) {}
}
}
See how much better the Java 7 version is :)
You should always close in finally because if an exception rise, you won't close the resources.
FileChannel srcChannel = null
try {
srcChannel = xxx;
} finally {
if (srcChannel != null) {
srcChannel.close();
}
}
Note: even if you put a return in the catch block, the finally block will be done.
eclipse is warning you about the FileInputStream and FileOutputStream that you can no longer reference.

EOFException in Java Android? Help needed

I am trying to do some kind of serialization where I can directly read and write objects from file.
To start of I just tried to write a character to file and tried to read it. This keeps giving me EOF exception always.
I am trying it on a Android device. Here is my code:
public class TestAppActivity extends Activity {
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
try {
WriteToFile();
Load();
} catch (Exception e) {
e.printStackTrace();
}
}
public void Load () throws IOException
{
InputStream fis;
ObjectInputStream in = null;
try {
fis = new FileInputStream(Environment.getExternalStorageDirectory() + "\\test2.ser");
in = new ObjectInputStream(fis);
char temp = in.readChar();
} catch (IOException e) {
e.printStackTrace();
} finally {
in.close();
}
}
public static void WriteToFile() throws Exception {
try {
OutputStream file = new FileOutputStream(Environment.getExternalStorageDirectory() + "\\test2.ser");
ObjectOutput output = new ObjectOutputStream(file);
try {
output.writeChar('c');
} finally {
output.close();
}
} catch (IOException ex) {
throw ex;
}catch (Exception ex) {
throw ex;
}
}
}
In this case, EOFException means there is no more data to be read, which (again in this case) can only mean that the file is empty.
Why are you using ObjectInput/OutputStreams but only writing chars? You'd be better off with DataInput/OutputStreams for that usage.
Also there is no point in catching exceptions only to rethrow them.
Also there is no point in reading a char from a file unless you are going to put it somewhere other than in a local variable that isn't even returned by the method.
I have imported this code in my sample project with following change.
i replaced "\\test2.ser"with "/test2.ser" and it worked. please try this.

Is it okay to use try catch inside finally?

I am using a buffered writer and my code, closes the writer in the finally block. My code is like this.
...........
BufferedWriter theBufferedWriter = null;
try{
theBufferedWriter =.....
....
......
.....
} catch (IOException anException) {
....
} finally {
try {
theBufferedWriter.close();
} catch (IOException anException) {
anException.printStackTrace();
}
}
I have to use the try catch inside the clean up code in finally as theBufferedWriter might also throw an IOException. I do not want to throw this exception to the calling methos. Is it a good practice to use a try catch in finally? If not what is the alternative? Please suggest.
Regards,
Hiral
A somewhat nicer way to do this is to use IOUtils.closeQuiety from Apache commons-io. It keeps your code tidy and eliminates some of the boilerplate that's inherent in Java.
You code then becomes:
BufferedWriter theBufferedWriter = null;
try{
theBufferedWriter = ...
...
} catch (IOException anException) {
...
} finally {
IOUtils.closeQuietly(theBufferedWriter);
}
Much nicer and more expressive.
In pre Java 7, I'd say what you have written is the best solution.
In Java 7 and onwards you have Automatic Resource Management intended to simplify these things. With this feature, you can do
BufferedWriter theBufferedWriter = null;
try (BufferedWriter theBufferedWriter = ...) {
....
......
.....
} catch (IOException anException) {
....
}
Or you can use Lombok and the #Cleanup annotation and you shall never write a try catch inside finally again.
This is how you would normally write it (Note the throws IOException):
//Vanilly Java
import java.io.*;
public class CleanupExample {
public static void main(String[] args) throws IOException {
InputStream in = new FileInputStream(args[0]);
try {
OutputStream out = new FileOutputStream(args[1]);
try {
byte[] b = new byte[10000];
while (true) {
int r = in.read(b);
if (r == -1) break;
out.write(b, 0, r);
}
} finally {
out.close();
}
} finally {
in.close();
}
}
}
Now with Lombok you just write #Cleanup on the streams
import lombok.Cleanup;
import java.io.*;
public class CleanupExample {
public static void main(String[] args) throws IOException {
#Cleanup InputStream in = new FileInputStream(args[0]);
#Cleanup OutputStream out = new FileOutputStream(args[1]);
byte[] b = new byte[10000];
while (true) {
int r = in.read(b);
if (r == -1) break;
out.write(b, 0, r);
}
}
}
This is what we will have to live with until Java 7 and ARM Blocks.
It's OK but you should test if theBufferedWriter is not null before closing it.
You could also do:
BufferedWriter theBufferedWriter;
try {
theBufferedWriter = new ...
try {
...
} finally {
try {
theBufferedWriter.close();
} catch (IOException closeException) {
closeException.printStackTrace();
}
}
} catch (IOException anException) {
...
}
or:
BufferedWriter theBufferedWriter;
try {
theBufferedWriter = new ...
} catch (IOException createException) {
// do something with createException
return; // assuming we are in a method returning void
}
try {
...
} catch (IOException anException) {
...
// assuming we don't return here
}
try {
theBufferedWriter.close();
} catch (IOException closeException) {
closeException.printStackTrace();
}
but mostly I do such operations (e.g. writing a file) in a dedicated method and prefer to throw the/an Exception so the caller can handle it (e.g. asking for another file, stopping the application, ...):
void someMethod(...) throws IOException {
BufferedWriter theBufferedWriter = new ...
try {
...
} catch (IOExcepption anException) {
try {
theBufferedWriter.close();
} catch (IOException closeException) {
closeException.printStackTrace();
// closeException is not thrown, anException represents the main/first problem
}
throw anException;
}
theBufferedWriter.close(); // throws the Exception, if any
}
Please note: English is not my first nor my second language, any help would be appreciated
It's ok to put a try-catch in a finally. It is the tool that does what you want to do. However, I feel the thrown IOException on close is uncommon enough that I would allow it to suppress any exception in the body like so.
try {
BufferedWriter writer = .....
try {
.....
} finally {
writer.close();
}
} catch (IOException e) {
....
}

Categories

Resources