Re: [Wpg-proxy-development] design details and impact on unittesting

[Alan M. <a_j...@ya...>]

Hi John,
   
  I think the following is how exception handling would normally be done:  We define ProxyException (plus possibly one or two other types depending on our needs) - this has the usual constructors i.e., message constructor, exception constructor, throwable constructor etc. that allow us to instantiate a ProxyException with a custom message e.g.,
   
  new ProxyException("Remote host cannot be contacted!");
   
  or nest our exception in another one, e.g.,
   
  try {
   ...try to do something...
  } catch (IOException e) {
     throw new ProxyException("Cannot establish connection", e);
  }
   
  all the usual methods are on ProxyException (e.g., getMessage, getCause etc.)  There is generally no need to put into a stack trace anything other than exceptions info - the context will extract what it needs when raising an exception e.g.,
   
  new ProxyException("cannot connect to host " + request.getHost()); 
   
  etc.  but sometimes it is necessary (e.g., in a specific subclass of ProxyException) to add state information e.g., a RemoteServerException extension of ProxyException might offer a getHost method etc.
   
  Now to types: we instantiate ProxyException when we need to report different circumstances that give rise to a proxy error (e.g., with different messages etc.) but we used different _types_ (e.g., subclasses of ProxyException) when we want to control flow e.g., in try/catch blocks or within the template method of a handler etc. or when we have context state information that needs dealing with.
   
  Types would be used when you are suggesting enumerations - I really don't think we should return codes, enums or similar in this context (they can be used for control of FSAs and that sort of thing but not here :)
   
  I will add the "canoncial" ProxyException class tonight with all the usual constructors and stuff and you can see what I mean above - this approach would be recognisable to Java developers and that recognition is probably important since it may be client code that has to deal with this.  To stimulate discussion I'll also add the ExceptionHandler stuff that allows us to "outsource" callbacks to the client code - this could clear up a lot in one go.
   
  hth.
  A.

John Southerland <jo...@we...> schrieb:
  Alan,
What would you think of us creating our own ProxyException which can hold
the stack trace of the original exception, plus a custom error message, and
getRequest(), getResponse() methods that will let the handler walk the
stack, go into the request or response, and log or record the error however
it likes.
The only thing I don't like about making our own exception is having to
figure out how to specify the exact error in a way that will be useful to a
programmer trying to develop an exception handler method.
I originally just renamed the two failed methods that are called when an
error happens during the request processing, and the response processing.
We could change that to a single failed( ProxyException ) method with the:
getRequest(), getResponse() methods plus an errorState() method to return
something like:
0 = before request is parsed, or init
1 = during request parsing
2 = while attempting to service the request
3 = during response parsing
...

Possibly an Enumeration??

Alan, Juan, please feel free to toss a recommendation out, I am struggling
to identify a usable model. I would not mind doing the ProxyException, and
can already see how my code would take advantage of that design, however, it
may have hidden gotchas I can't see.

Remember, one of my favorite things is to print a stack trace with an error,
and Exceptions are so good at that, but also we can print that stack trace
in the proxy before sending it on to the handler, so that may be the best
place for that.

That being said, I have no idea......




-----Original Message-----
From: John Southerland [mailto:jo...@we...] 
Sent: Monday, January 29, 2007 5:54 PM
To: 'wpg...@li...'
Subject: RE: [Wpg-proxy-development] design details and impact on
unittesting

I should point out one of the reasons I see for passing the exception is the
processors and handlers have no context beyond the call itself. The objects
do not get destroyed so it is conceivable that the developers could
implement a more advanced object that has some internal stuff, but the usage
should be to not store any state, but to accept these interupt driven
events. That is why the callbacks each take an HttpMessage as an argument.

If an error occurs during the actually sending and receiving of the request
we need to inform the handlers and pass them any data we have available so
they can "handle" it along with our proxy. Again, the handlers will have no
context to the method calls the proxy issues during processing of the
requests from the clients, so we need to pass as much as possible in the
call. Though not entirely explored in my mind yet these handlers may get
called more often than you would initially imagine in a serial system. 

I thought originally about extending an abstract class but then decided
against it so the programmer would not have to worry about our internal
classes, and could simply take an existing class and implement the handler
or process or both on top of it, as in many swing interfaces. I would
rather force the programmer to write more methods.

Let me refactor what we have into something a little more clear and then
look at better error handling in the handler class. This may help us when
refering to the different logical calls.
Thanks, John 


-----Original Message-----
From: wpg...@li...
[mailto:wpg...@li...] On Behalf Of
Alan Moran
Sent: Monday, January 29, 2007 4:47 PM
To: wpg...@li...
Subject: Re: [Wpg-proxy-development] design details and impact on
unittesting

Hi All,

adding my 2c based on what we have discussed
already....

> Currently the HttpMessageProcessor does the
> following three methods for each
> request and response if registered
[snip] 
> The goal of this interface is to allow the
> programmer to either modify the
> message with the process method before allowing it
> to continue down the
> line, to filter this message via the doSend and
> doContinue methods, or both.
> Based on the usage and definitions a better name is
> needed to keep confusion
> to a minimum. 
> I think this interface and all references to it
> would be better named
> "Filter" or "Translator" What do you guys think????

I think that Filter or Handler (or even Processor) are
fine names that convey that idea of one step in a
sequence or chain of events. I think each processor
(or whatever we call it) needs a well defined
lifecycle concerning what is does (not how it is
called, i.e., if it is to continue then this is a
decision to be made its calling context etc.)

> Second, the HttpMessageListener is not a listener
> and needs to be refactored
> based on that, also the error methods need to be
> rearchitected to be
> cleaner, and the received methods are confusing and
> ugly. This whole thing
> needs redesign.

Agreed. Listener makes it sound like an Observer
which it is not! In fact I kinda doubt the
processor/listener distinction is in fact a real
one...but I will study the code some more and touch up
my UML tomorrow.

> Currently HttpMessageListener looks like this:
> 
> 1. void failed( Exception e ) // failed to even
> receive a request from
[snip...etc.]

The passage of Exceptions as arguments is a first for
me - I'm not sure whether I should laugh or
cry...anyhow the listener/processor needs only to
notify exceptions (i.e., throw them) and the calling
context should decide what to do. Here are two
possibilities:

1. throw/catch with the option of passage the matter
back to the proxy client (not very nice since the user
may not want to get involved in that sort of thing)

2. define an ExeptionHandler that defines callbacks
for each type of exception that can be raised. The
binding of callback to exception is typical template
method stuff and can be managed in a base class. The
client code can optionally implement an
ExceptionHandler (failure to do so means a default one
is used) etc. An example of this sort of thing is the
ErrorHandler that one sees with SAX parsing
architectures.

> Next, the received methods which are overloaded to
> handle both requests and
> responses should probably be renamed receivedRequest
> and receivedResponse
> respectively to clarify when each is called. Then
> the error handlers should
> be less overloaded and more descriptive in their
> calling state. In that
> vein, should we create a hierarchy of Exceptions to
> organized the errors
> causing the call, or an error enumeration to help
> organize the messages? 

The idioms of request/response handling ought to
follow those that most developers would be familiar
with in NIO or similar - so we can just take our lead
from that perhaps. 

Exceptions are typed so that we can distinguish error
events - we can easily afford to define a handful of
exceptions (perhaps based in a single class), this
sort of exception hierarchy is common and might even
be expected of us. It would also bind nicely to the
ExceptionHandler suggestion above if we choose to go
down that route. Not so sure about the enumeration -
that is not very Java-ish, better define types instead
(i.e., classes.) Each exception class should of
course contain message information about the errors
etc. and should support all the usual features of
exceptions classes (e.g., support throwable, nested
exceptions etc.)

I think we should brace ourselves for a bit of a
rewrite of the interfaces but from I have seen of
John's stuff already I think that much of the
internals can be kept. In all once we have a robust
API then the refactor itself will take no time at all.

hth,
A.



___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wpg-proxy-development mailing list
Wpg...@li...
https://lists.sourceforge.net/lists/listinfo/wpg-proxy-development


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wpg-proxy-development mailing list
Wpg...@li...
https://lists.sourceforge.net/lists/listinfo/wpg-proxy-development


 		
---------------------------------
NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever.