Jigsaw resolver error handling

[Mark Reinhold]

> Date: Sun, 10 May 2009 17:33:07 -0700
> From: jonathan.gibbons at sun.com

> 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.

Agreed.  Right now "error handling" is limited to throwing pretty much
just one exception type (ConfigurationException), and when the resolver
fails the message is not at all helpful -- it gives you no clues as to
why it failed.

> 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.

Yes.  I tend to prefer fairly fine-grained exceptions, in part exactly
for this purpose.

> 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. :-(

Couldn't agree more.

- Mark