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

[<ju...@ag...>]

Hi Alan,

2007/1/31, Alan Moran <a_j...@ya...>:
>
> Hi John,
>
> I think the following is how exception handling would normally be
>
[snip]

>
> I will add the "canoncial" ProxyException class tonight with all the usua=
l
> 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.
>
I agree we should keep using the exception infraestructure for error
handling, but I also believe it's not that hard to include the "state" enum
suggested by john, just as an aditional source of info to know where to
start seeking for the problem when an error happens, just something like:

public enum ProxyErrorType {
    BeforeRequest,
    ParsingRequest,
    ServingRequest,
    ParsingResponse;

    private String message;
    ProxyErrorType(String message)
    {
        this.message =3D message;
    }

    public String getMessage() {
        return message;
    }
}
 And including a constructor to ProxyException base class like:

 public ProxyException(ProxyErrorType type, Throwable cause) {
        super(cause);
        this.type =3D type
    }
Of course with a private property and a getter for it.

What do you think of it? It is just another way to classify the errors we
can get, but maybe what we need is to define a class containing the
"Context" of the given error (of course the needed fields for the "Context"
class have to be determined), and include that information with the
ProxyException so it can be handled from the caller, does it make sense?

To stimulate discussion I'll also add the ExceptionHandler stuff that allow=
s
> us to "outsource" callbacks to the client code - this could clear up a lo=
t
> in one go.
>

I'm just waiting to see it ;)

hth.
> A.
>

Just my 0.02=80
Juan.