RE: [java-gnome-hackers] Error reporting

[Jeffrey M. <Jef...@Br...>]

This is an excellent topic.  Thank you for bringing it up Tom.
Currently we do not have a consistent approach for handling
errors.  Some methods return null, some methods throw exceptions,
and some methods do no error checking at all (leading to
NullPointerExceptions at runtime).  I personally like the proactive
Exception approach.  What does everybody else think?  We should
also discuss the creation of a package to contain java-gnome
specific exceptions if this is the approach we plan to take.

> Jeffrey,
> 
> The Jackpot project has a project review this Friday which will decide
> what I'll be working on going forward at Sun Labs (happily 
> the layoff ax
> passed over most of us).  We've been in firedrill mode the past few
> weeks, but next week I'll be able to devote more time to the libglade
> work and can give you a reasonable schedule.
> 
> One general question belongs on your list, unless it's already been
> decided:  how should exceptional conditions be handled?  Libglade, for
> example, follows the normal C library convention of returning 
> NULL from
> its "read and parse the glade file" routine, but doesn't provide any
> sort of other feedback to the developer (unless they having logging
> enabled and check the log).  Is that the convention for all of
> java-gnome?
> 
> My preference is to map likely problems to existing or new exception
> classes.  For libglade, that includes checking that the file exists
> (FileNotFoundException), that it can be read successfully 
> (IOException)
> and that it contains a valid XML description (new 
> GladeXMLException).  I
> don't want to require a different coding style than the rest of
> java-gnome, however.
> 
> To make these exceptions more useful, I have almost working code that
> "catches" the message logged by the libglade-2.0 library and uses that
> the message of the thrown exception.  If exception mapping is 
> chosen for
> the whole project, I should be able generalize this code and make it a
> common utility function somewhere.
> 
> The reason I bring up exception handling is that not having 
> them now and
> then changing policies later can frustrate our clients.  I comfortable
> with either C-style or Java-style error handling, as long as its
> consistent across our libraries.
> 
> Tom
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing 
> your web site with SSL, click here to get a FREE TRIAL of a Thawte 
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>