Jigsaw resolver error handling

[Jonathan Gibbons]

Mark,

I'm sure this is not high on your list of priorities right now, but at  
some point we should think about how best to handle error handling, at  
least as far as the ModuleResolver is concerned.

The current API leads me to think that you might be formatting English  
language messages.

javac expects to be able to set the Locale used for messages.  If  
nothing else, it would be convenient if in time we identified Jigsaw- 
specific subtypes of ConfigurationException such that javac could  
handle/respond to them directly.

As an example, consider FileNotFoundException as a special subtype of  
IOException that is often handled differently, with customized error  
messages.  I would like to take it one step further, and add custom  
arguments/fields for custom exception subtypes -- something JDK is  
woefully inadequate at doing.  For example, FileNotFoundException  
should really make available the specific file in question, leaving  
clients to "guess" that the detail message may be the file name,  
although that behavior is not specified.

In the modules world, I'm sure there will be an similar  
"ModuleNotFoundException". In this case, it would be useful to know  
the id of the module in question, and the context (module) within  
which the reference was found.  javac will need this information in a  
reliable type safe way (no parsing of detail messages, please) so that  
it can tie individual errors back into the user's source code when  
necessary.  Otherwise, we are going to be left with javac reporting a  
non-informative error, like "Error: cannot find module M at 2.0" with no  
context available at all. :-(

-- Jon