Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / First Aid / December 2005

Tip: Looking for answers? Try searching our database.

how to handle errors and preconditions

Thread view: 
Petterson Mikael - 08 Dec 2005 14:59 GMT
Hi,

I have an interface that looks like this:

/**
 * @author eraonel
 *
 */
public interface IConstraint {
   
    /** Method for validation of a specific constraint */
    void validate (MomDataReader mdr);
   
   
}

All XXconstraint classes implement this interface.

In one XXconstraint class I have the following impl. of validate ( see
below).

I only want to print the Ok! lines when I have debug on.
Errors shall always be printed and nicely written to file.
When a precondition is not fullfilled then I want to throw a
ValidateException(String msg).

What is a good way to approach this matter?
All design hints are welcome.

cheers,

//mikael

//validate
public void validate(MomDataReader mdr){
   
        // get all actions in the mon
        MomClass [] clazzes = mdr.getAllClasses();
        for (int i = 0; i < clazzes.length; i++) {   
            MomClass clazz = clazzes[i];
            MomAction[] actions = clazz.getAllActions();
            if (actions != null) {
                for (int j = 0; j < actions.length; j++) {
                    MomAction action = actions[j];
                    String actionName = action.getName();
                    if(actionName.matches("[a-z][]A-Za-z0-9]*")){
//Ok!                        System.out.println("Class: "+clazz.getName()+" action :
"+actionName+"Ok!");
                    }else{
                       
//Error                        System.out.println("Class: "+clazz.getName()+" action :
"+actionName+"Error!");
                       
                    }
                }

            } else {//Precondition not fullfilled to validate
                System.out.println("No actions for Class: "+clazz.getName());
            }
        }
       
    }
Rhino - 08 Dec 2005 15:28 GMT
> Hi,
>
[quoted text clipped - 56 lines]
>
> }

The technique I use is to have a static final class boolean named DEBUG in
my class. I hard-code it to true or false and then have code like this
throughout the program:

if (DEBUG) System.out.println("foo: " + foo);

Rather than making DEBUG a class variable, you could also pass it in from
the invoking class or put it in an interface shared by all classes that you
want to debug. Of course, that will turn on debugging for all classes that
get executed, not just the one that is giving you trouble; since that's not
normally what I want, I use a separate DEBUG variable (constant!) for each
specific class so that I can turn each on or off separately.

Again, a DEBUG class variable is probably not the best way to handle this
problem. Assertions may be the best way to go. See
http://java.sun.com/developer/Books/javaprogramming/jdk14/javapch06.PDF for
a discussion of assertions. This approach would let you enable assertions in
a single class or in many classes from outside the program; that might be
more convenient than changing a class variable from false to true and
recompiling the program.

Rhino


Oliver Wong - 08 Dec 2005 17:39 GMT
> The technique I use is to have a static final class boolean named DEBUG in
> my class. I hard-code it to true or false and then have code like this
[quoted text clipped - 9 lines]
> (constant!) for each specific class so that I can turn each on or off
> separately.

   The problem with this is sometimes you want to turn on DEBUGing globally
in all classes. Or turn it off globally (when shipping the finished product,
for example). Or sometimes you only want it enabled in certain packages.

   Take a look at how the logging API handles that. It uses a factory
methods (e.g. getLogger()) to construct loggers within a hierarchal
namespace. Usually that namespace hierarchy reflects the package structure
hierarchy, which makes it easy to turn logging on and off for an entire
package, but it doesn't nescessarily have to be that way.

   - Oliver
Rhino - 08 Dec 2005 18:17 GMT
>> The technique I use is to have a static final class boolean named DEBUG
>> in my class. I hard-code it to true or false and then have code like this
[quoted text clipped - 14 lines]
> finished product, for example). Or sometimes you only want it enabled in
> certain packages.

Agreed! I believe that assertions are the recommended approach for that
exact reason.

>    Take a look at how the logging API handles that. It uses a factory
> methods (e.g. getLogger()) to construct loggers within a hierarchal
> namespace. Usually that namespace hierarchy reflects the package structure
> hierarchy, which makes it easy to turn logging on and off for an entire
> package, but it doesn't nescessarily have to be that way.

Good example!

Rhino
Mark - 09 Dec 2005 04:05 GMT
Certainly using a logging package is the best way to solve this issue
for any serious application.
Especially given that you already want to log errors:
"Errors shall always be printed and nicely written to file."
The biggest advantage is that you will be able to change the logging
parameters (eg only log errors, or include debug messages) without
re-compiling.

If this is only a small application, then it may not be worth the
effort and you could use the DEBUG constant idea explained earlier.

If you wish to use a logging package, you could use Java's logging
framework (java.util.logging) or Apache's Log4J
(http://logging.apache.org/)


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.