This internal error message is not designed to be valid XML or machine
readable. It was just some for of human readable mark-up which is used
to delineate the separate components of the message. Maybe it was a
mistake to use a syntax that looked like it should be XML.
There is no expectation that the output of the message will be parsed
and errors interpreted by another program. It was just meant to be
something that a user would notice in their logs.
Instead of outputting:
<log4net.Error>Exception during StringFormat: Input string was not in a
correct format. <format>Hello
{0}{1</format><args>{<World}</args></log4net.Error>
we could do:
log4net.Error: Exception during StringFormat: Input string was not in a
correct format.
format: Hello {0}{1
args: <World
But to do this in a valid way we would probably need to encode newlines.
Users may be less confused by this non XML looking form.
What do you think?
Nicko
> -----Original Message-----
> From: Ron Grabowski [mailto:[EMAIL PROTECTED]
> Sent: 03 April 2006 01:31
> To: [email protected]
> Subject: Are <log4net.Error> messages guaranteed to contain valid XML?
>
> I noticed this snippet of code:
>
> log.DebugFormat("Hello {0}{1", "<World");
>
> is correctly caught as containing an invalid format string.
> This is part of the error message:
>
> <log4net.Error>Exception during StringFormat: Input string
> was not in a correct format. <format>Hello
> {0}{1</format><args>{<World}</args></log4net.Error>
>
> Notice the unclosed greater than sign before World. Shouldn't
> we be encoding (or CDATAing) certain XML characters when we
> generate XML messages? I couldn't find anything saying error
> messages will rednered as XML.
>
> log4net.ObjectRenderer.RendererMap.FindAndRender and
> log4net.Util.SystemStringFormat.StringFormatError both
> generate those style messages.
>
