On Sep 16, 2011, at 7:41 PM, Joern Huxhorn wrote:
>
> On 16.09.2011, at 19:09, John Vasileff wrote:
>
>>
>> On Sep 15, 2011, at 7:46 PM, Ralph Goers wrote:
>>
>>> My gut reaction is that I agree with you. I ran across this behavior a
>>> while ago and Joern mentioned that ParameterizedMessage was working the way
>>> it is supposed to, which given the behavior you are noting just doesn't
>>> seem correct.
>>>
>>> On the other hand, currently not every Message implementation cares about
>>> Throwables. I'm not sure what StructuredDataMessage should do with one,
>>> for example. What do you think should be done to handle that?
>>>
>>
>> I think it is analogous to getParameters(). It is a common feature, but not
>> one that all Message types need. So I think the question is how granular
>> the interfaces should be. Message could have _only_ getFormattedMessage(),
>> and everything else added by sub interfaces. But for very common things
>> like Throwables or Parameters, I tend to think it is easier to have them in
>> the main Message interface and avoid instanceof clutter in the rest of the
>> code.
>>
>
> I wonder why you are so keen to extend the basic Message interface with
> arbitrary methods that are only relevant for certain Message implementations?
>
> The Runnable interface does also only have a run() method and not some
> obscure Object[] getArguments() / void setArguments(Object[]) methods.
>
It is not so much that I think the Message interface should have
getThrowable(). It is that I think that message objects should carry the
throwable, if one exists.
void info(Message msg);
void info(Message msg, Throwable t);
I don't think the second method above should exist, just as we don't have:
void info(Message msg, Object[] params);
I would be happy to rework the patch with something like:
interface Message { public String getFormattedMessage(); }
interface ThrowableMessage { public Throwable getThrowable(); }
interface ParameterizedMessage { public Object[] getParameters(); }
etc.
We would need to think through the appropriate granularity and try to figure
out what the best mix of interfaces is.
I agree keeping getThrowable() out of Message would be more pure from a design
standpoint. The reason I lean towards adding it is that since it is so common,
it avoids several instanceof checks. A bit of a compromise for convenience
sake. (Not that instanceof is great from a design standpoint either, but it is
inherent in concept of having Messages.)
>
>> SimpleMessage has:
>>
>> /**
>> * Returns null since there are no parameters.
>> * @return null.
>> */
>> public Object[] getParameters() {
>> return null;
>> }
>>
>> So StructuredDataMessage can have:
>>
>> /**
>> * @return null; StrucutredDataMessages never have Throwables.
>> */
>> public Throwable getThrowable() {
>> return null;
>> }
>>
>
> But what about tracing messages? Those could have a TraceMessageType
> (ENTERING, EXITING, THROWING).
> Shouldn't we add that to the Message interface, too, and just return null in
> case of every other Message implementation?
>
> Sorry about my sarcasm (and yes, that's only sarcasm. I'm not suggesting to
> add this to the Message interface ;)) but I just don't see the reason and
> rationale for those methods.
>
> Joern
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
