RFE: Phase_1-File Formats -1 handle new compression format exception

[jamoore]

Users should be informed that this is a format we support, but not a compression we support.

See #5245.

Also, somewhere in the stack the exception is being printed to stdout or stderr. This should be removed. See stack trace below.

[jmoore]

printed on console:

loci.formats.FormatException: Compressed LIM files not supported.
	at loci.formats.in.LIMReader.initFile(LIMReader.java:115)
	at loci.formats.FormatReader.setId(FormatReader.java:1072)
	at loci.formats.ImageReader.setId(ImageReader.java:670)
	at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:488)
	at loci.formats.ChannelFiller.setId(ChannelFiller.java:249)
	at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:488)
	at loci.formats.ChannelSeparator.setId(ChannelSeparator.java:257)
	at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:488)
	at ome.formats.importer.ImportCandidates.singleFile(ImportCandidates.java:406)
	at ome.formats.importer.ImportCandidates.handleFile(ImportCandidates.java:574)
	at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:367)
	at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:335)
	at ome.formats.importer.ImportCandidates.execute(ImportCandidates.java:367)
	at ome.formats.importer.ImportCandidates.<init>(ImportCandidates.java:228)
	at ome.formats.importer.ImportCandidates.<init>(ImportCandidates.java:179)
	at ome.formats.importer.gui.FileQueueHandler$1.run(FileQueueHandler.java:290)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:680)

[jmoore]

Handling initial support now, rather than requesting feedback from users. This should probably be evaluated as part of 4.3.0.

[jmoore]

commit 7907c6e5296c860ca69b0dbfad017788e6ec9bcd
Author: jmoore <josh@glencoesoftware.com>
Date:   Tue May 17 12:00:38 2011 +0200

    Adding initial support for `UnsupportedCompressionException` (See #5245)

[jburel]

Moved from sprint 2011-05-19 (12)

[jburel]

2 things in this ticket: the second point should probably be considered as a bug.

[jburel]

who is doing it? no owner

[jmoore]

The primary issue of compression formats showing up as QA uploads is taken care of. Brian, could you take care of the printing of the stack trace? If we want to improve feedback on compression, etc, we'll take care of that with the rest of the refactoring. Jean-Marie, do you have a story or ticket you could add that too?

[jburel]

we have stories related to notification requirement #2114. Depending on the tasks, we should find a story under the requirement we can attach the tickets to.

[jmoore]

It's less about notification, and more about what a user should expect when they click on a file we don't support. In reality, the UnsupportedCompressionException should be a subclass of UnknownFormatException since it's not like the user can do anything about it, other than suggest we prioritize implementing codec.

[jburel]

a bit of both, in order to notify correctly we need a more accurate exception.
He/she cannot do anything about it directly but by displaying the correct information will be able
to come back with good questions/requirement.
Improved Exception goes under the"notification" banner in that case similar to MissingPyramid in a way

[bwzloranger <bwzloranger@…>]

(In [b66516ae5ccc7b119d3e596ee3a6b81c2a7f3243/ome.git] on branch develop) Fixes #5246 (printing to stderr removed)