CompilerException explicit handling

[Jorge Lavin]

Based on the following two observations:

1. The method public CompilationPackage compile(Map<String, String> classesToCompile) throws CompilerException of the class InMemoryCompiler declares that throws that Exception, therefore enforces to be handled explictly. Of course same applies to singleCompile

2. In the tl;dr use case this exception is not handled, probably delegated to the main(String[] args) method or a unit test

Three proposals for a more flexible (end user point of view) approach, the three of them imply removing the explicit throws of the methods:

1. Provide a null-like CompilationPackage so that BaseCompilationPackage is an interface that is implemented by NullCompilationPackage and CompilationPackage (say).

2. Provide a way to access the compilationReport in the CompilationPackage so that the user of the compiler can decide what to do with the CompilationPackage result.

3. A combination of both 1 and 2.

A use case is an interface declaring a single method such as:

public interface CompilationPackageGenerator<T> {
    CompilationPackage compile (T t);
}

whose implementation may be

@Override
public CompilationPackage compile(Foo foo)
{
	HashMap<String, String> classes = irrelevantSourceCodeSupplier(foo);
	try
	{
		return inMemoryCompiler.compile(classes);
	}
	catch (InMemoryCompiler.CompilerException e)
	{
		e.printStackTrace();
	}	
	return null;
}

The return null is the part that lead me to open this ticket. I don't want to add throws CompileException to the interface.

[picadoh]

Closing this issue as this concern should be covered by the latest code version.