| Re: [udig-devel] standard way to do file access and exception throwing |
Jesse Eichar wrote:
I have looked at catalog implementations that take this approach; uDig does not provide this kind of low level support. It is more a platform for visually integrating what you already have. Thinking ...1) what is used to wrap a file access in a standard way? We had something like a datasource which just decided if it was a file: or smb: or http: and had facilities to get readers, writers, stream and so. I'm sure this is also in udig, but I can't find it. If not, what is the logic to follow?I don't have a good answer here. Jody?
If you look at recent eclipse builds they have done a neat trick. They have methods on their IResource instances that return something that is "almost" like a Java File. Pretty sure this is in Eclipse 3.2?
Can you look at this facility and see if it works for you? I would like to stick with normal eclipse constructs as often as possible.
We follow eclipse conventions; usually each extension point lets you know what you are allowed to do. My preference is to have the extension point processor take care of error reporting, setting a warning in the status bar (or simply attaching a warning to a GeoResource etc...).2) how to properly throw exceptions? When to send in red to the statusbar? Is there a way to open a dialog with the error description and a log to send? How is this dealth with in general?
Can I ask for the specific context in which you are trying to handle the Exception? For a uDig operation you should just be able to "throw" and uDig will take care of the notification. For Tool things are a bit more scary (since an error may be in the event loop).
We haven't nicely come up with a solution to this yet. The main thing we do is add a logging method in the Activator class of the plugin and directly log to that. There are a few areas that you can put errors. One place is on the GeoResource or Service. There is an error message and a Throwable that you can set. If you are in a renderer you just have to throw an exception and it will be set in the status bar for that layer. Layers also have a status and a status message. This is an issue that needs to be better discussed at some point as it is kind of ad hoc now. I think Cory started an ErrorManager but it is a long way from complete.Hi Jesse :-) You are on the same page as me. Andrea we can check our eclipse books again to see if there is any best practice we have missed out on. But so far normal Framework advice is the best (capture the error handling as part of managing the extension point and don't force any error handling code on contributors).
Jody