Community
Participate
Working Groups
Trying to use ResourceSet.getResource(URI,boolean) I kept getting java.lang.RuntimeException: Cannot create a resource for 'file://D:\dir\file.ext'; a registered resource factory is needed although a factory for the given extension was indeed registered. Only by debugging ResourceSetImpl I could see that this was caused by an empty fileextension of the given URI, which was easily fixed by removing the extra '/' after 'file:'. Wouldn't it be nice if the error would tell me what's wrong with the URI rather than complaining about a missing factory? At least mentioning the fileextension used for factory lookup (here: ""!) would be a treat :)
It's not just a case of registering against an extension; you can register against the protocol/scheme, or use content type registrations. Even if we said the extension was "" you'd still wonder why it's not "ext" and you'd still likely need to use your trusty debugger to figure out why it's not what you thought it should be.
Hi Ed, with all due respect your answer doesn't convince me. Please note that I'm just an occasional EMF user, and even more: my contact with EMF is mostly indirect while applying XText etc. I'd love to just use this great stack of frameworks without needing to know how it works internally. (In reply to comment #1) > It's not just a case of registering against an extension; you can register > against the protocol/scheme, or use content type registrations. This only means the error message would perhaps need a few more details like I tried scheme 'file:' and extension '' but couldn't find a factory. > Even if we said the extension was "" you'd still wonder why it's not "ext" and > you'd still likely need to use your trusty debugger to figure out why it's not > what you thought it should be. Yes but there's a huge difference: when figuring out why it's "" and not "ext" I'd be debugging my own code (the part that constructs the URI from a string). Instead, the existing error message first gave a hint that something about the factory registration is wrong (so I spent considerable time debugging how XText registers factories and how these are later retrieved by EMF). This hint turned out to be all wrong: all factories are perfectly in place, but to come to this conclusion I had to learn some internal details that I didn't want to learn actually. To make a long story short: is EMF *intended* to be used by occasional users who cannot afford to learn about the inner workings? The current issue is one out of a number of examples where I as a novice in modeling had the impression: "it works great if it works, but if I make a mistake, there's little help for finding out what exactly I screwed up". Perhaps my expectations are skewed because in all my work on compilers the better part of my time is spent in improving error/warning messages so that users (who may have limited knowledge of the language they're using) get optimal hints on how to fix their broken programs. Doesn't this apply to core technology like EMF, too?
Given you've had a close look at the code, you can see that the logic for the resource factory implementation is quite complex such that by the time all efforts have failed (all registrations in the local registry and all registrations in the global registry fail to produce a result), the reasons for failure are many. Not only that, the exception is thrown in a place that actually knows nothing about the logic for how the resource is demand created. The exception is there in the first place only because people complained they didn't know why the method was returning null. So it's not clear how much explanation one should generate based on assumptions about the default implementation. Suppose for example that you had a content type registration but the content didn't conform to the content type so the registration didn't apply. You can imagine the next guy will complain about that...
