Re: [udig-devel] standard way to do file access and exception throwing

[Andrea Antonello <andrea.antonello@xxxxxxxxx>]

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

Alright, it was just that I didn't feel good to use File and
BufferedReader or RandomAccessFile without thinking about remote files.
However a JGrass database will always be local, so I don't think there
will be problems. But you never know :)

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

I would be delighted, but I need a clearer direction to look at. I'm an
eclipse framework newbie...

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

Great. That is perfect.

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

Yes, that is very nice, if you are a contibutor like me :)
You were talking about eclipse books. Could you give me some reference
to a good book that also covers SWT? I think copy and paste won't be
enough at a certain point. :)

Andrea