obj,fn,parms encapsulation in java

T

Tim Jowers

i repeatedly see this pattern:

{ TBaseType ret = TBaseType.Factory.newInstance();
try{
// start some call //
dbControl.deleteSearchLog(logId);
// after some call //

} catch(SQLException sqe)
{ // return error code
ret.setErrorCode( "1" );
ret.setErrorMessage( sqe.toString() );
Log(""); ...
}
return ret;
}

where I have a method or segment of code that is 90% identical except
for a line or a few lines. What pattern makes this easy to work with?

The only idea I have is to create a class that takes an object, method
name, and parameter array and makes the call. Is that the typical
solution? It seems very contrived and hard to work with versus just
typing the code like
dbControl.deleteSearchLog(logId);
And seems to totally break if I have several statements. Then I have
to make a new method to hold each of the statements and somehow pass
all the required parameters...

Thanks,
TimJowers
 
A

Alan Meyer

Tim Jowers said:
i repeatedly see this pattern:

{ TBaseType ret = TBaseType.Factory.newInstance();
try{
// start some call //
dbControl.deleteSearchLog(logId);
// after some call //

} catch(SQLException sqe)
{ // return error code
ret.setErrorCode( "1" );
ret.setErrorMessage( sqe.toString() );
Log(""); ...
}
return ret;
}

where I have a method or segment of code that is 90% identical except
for a line or a few lines. What pattern makes this easy to work with?

The only idea I have is to create a class that takes an object, method
name, and parameter array and makes the call. Is that the typical
solution? It seems very contrived and hard to work with versus just
typing the code like
dbControl.deleteSearchLog(logId);
And seems to totally break if I have several statements. Then I have
to make a new method to hold each of the statements and somehow pass
all the required parameters...

Thanks,
TimJowers

If I understand what's going on here, it appears that
the programmer is converting an exception method of
handling errors into a more traditional return code
method.

I'm not sure what the benefit is? Without this code, the
programmer would have to catch an SQLException.
With this code he still has to test the return code and put
in pretty much the same logic. Instead of testing:

sqe.getMessage()
he tests:
ret.getErrorMessage()

I'm not sure what's gained.

Instead of that, what I usually do is define my own exception
class, e.g., class MyException(...).

It might have a constructor like:

public MyException (SQLException sqe, String whereabouts) {
// Extract the messages and SQL state, putting
// them into a uniform format, e.g.,
msg = "SQLException at: " + whereabouts + ":\n"
+ sql.getMessage ...
// etc.
}

Then:

try {
whatever;
}
catch SQLException sqe {
throw new MyException (sqe,
"I was trying to do whatever when this occurred");
}

I might convert other exceptions into MyException too, so
I only have one exception type to test for in cases where all
I care about is that an error occurred. But with different
constructors for MyException I can do different things with
each other type that can create one.

Dunno if this is anything like what you wanted but, for
whatever it's worth, there it is.

Alan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top