Re: POE::Filter error reporting

I second this.

And I think something like POE::Filter::Error would be a good place to
encapsulate something like that. But like what was stated in IRC,
making the error appear in the normal data stream could be
problematic. I suggest a property on the filter itself store an error
object that can be checked if it returns undef  (a much simpler
indicator for error). This pattern is really no different than any of
the perl built ins when they set $!.

On 8/14/07, Martijn van Beers <martijn@xxxxxxxxxx> wrote:
> Hi,
>
> so with filters becoming more and more complex (e.g. POE::Filter::XML,
> Filter::HTTPD) I think it would be a good idea to have a standard way of
> reporting back errors.
>
> Currently Filter::HTTPD returns a HTTP::Response object instead of a
> HTTP::Request, to send back to the remote end. Filter::XML uses a
> callback mechanism, which you can attach to a POE event.
>
> Especially if you want to combine several complex filters into a
> Stackable one, this becomes problematic. Each would have to know about
> the way its predecessor in the stack reports problems.
>
> I suggest we decide on a standard object type to use for filter errors.
> For Filter::SAXBuilder I picked Error::Simple for now, but that may not
> be the best choice. With a standard object, Filter::Stackable could just
> skip over the rest of the stack when it encounters an error, so filters
> don't need to do any error handling of their own.
>
> Does anyone know a good CPAN module to use, or should we write our own?
> It could be something really simple, basically just a container for
> whatever you like, just blessed in a standard way so it can be
> identified as an error.
>
>
> Martijn
>
>