FileManagement package

Lots of work this past week on the FileManagement package.  Not yet finished, but getting close.  Note that JavaDoc comments are in need of tweaking and should not be trusted.
Good point.  In fact, the copyFiles method is currently only throwing exceptions for problems encountered in accessing/copying files and folders at the root of the sourcePathname.  Problems accessing or while copying sub-subfolders or files in those folders are passed over.  This is not how a (Windows at least) file manager would handle exceptions – it would bomb out at the first sign of an issue.  I’ll have the exceptions propagated up in all case.  This being a SwingWorker, any exception thrown within the doInBackground() method will actually get thrown as type ExecutionException, with the original reason (exception) available via the SwingWorker’s get() method via ex.getCause().

 

- Jeff

 

From: Spencer Marks [mailto:notifications@github.com] 
Sent: Monday, June 23, 2014 7:34 AM
To: JeffBlodgett/FileSieve
Cc: Jeff Blodgett
Subject: Re: [FileSieve] FileManagement package (#5)

 

In src/main/java/FileSieve/BusinessLogic/FileManagement/ConcurrentFileManager.java:

> +                        fileProgress = 100;
> +                        publish(new SimpleImmutableEntry(targetPathname, 100));
> +
> +                    } catch (SecurityException | IOException e) {
> +                        noErrors = false;
> +
> +                        setProgress((int) ((totalPercentPreviouslyCopied + fileBytes) * 100 / totalBytes));
> +                        publish(new SimpleImmutableEntry(this.targetPathname, getProgress()));
> +                        publish(new SimpleImmutableEntry(targetPathname, null));
> +
> +                        try {
> +                            if (Files.exists(targetPathname) && ((targetPathname.toFile().length() == 0L) || (soFar > 0))) {
> +                                Files.delete(targetPathname);
> +                            }
> +                        } catch (SecurityException | IOException ex) {
> +                            // Ignore exceptions - this is a best attempt at deleting the written file, which was cut short

Never, ever ignore exceptions. 
Exceptions must be handled in the code or passed up to the client caller. 
Ignoring a problem is not a valid way to handle it. 
Ignoring an exception is called 'dropping an exception' 
Exceptions are like eggs. You want to handle them carefully, never drop them, and wash you hands after using them. - Wait, not that last part, but the rest is really true. 
Otherwise, you could make yourself sick spending hours debugging a problem because the issue was carefully ignored somewhere deep in the code. This has happened to be. Well, not the sick part, unless you count sick with rage at the person who 'dropped the exception' and made debugging so much harder. 
Note: sometimes it does make sense to convert the checked exception to a runtime exception. The times this makes sense is when there's no possible way client code can deal with the problem effectively. Note sometimes != always or most of the time. More like once in a while. This might be one of those cases though. Not sure. 

—
Reply to this email directly or view it on GitHub <https://github.com/JeffBlodgett/FileSieve/pull/5/files#r14070664> .