On Wed, Jan 23, 2013 at 10:59:19AM -0500, MARKSTOS via RT wrote:
Show quoted text> Queue: Imager
> Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=24193 >
>
> When Imager throws an exception in my apps, I'm primarily interested to
> know one thing: Does it represent a coding bug, or bad data, in the form of
> a corrupt image that got passed in?
>
> To address this, I wrote a little routine that checks 'errstr', to match
> patterns that I believe are caused by corrupt images and are "not my
> fault".
>
> Based on the result, I might tell the user "try again" or apologize and
> generate logging that will notify developers.
>
> This seems like a common enough situation that it seems worth baking into
> Imager.
>
> My initial idea is to consider upgrading 'errstr' to an exception object
> that uses overloading to stringify to an string as it does not.
>
> Imager would classify exceptions "corrupt image" exceptions or general
> exceptions as they happen.
>
> A second idea would be to add a new method:
>
> Imager->throw;
> $imager->throw;
>
> Or more explicitly:
>
> Imager->throw_exception;
> $imager->throw_exception;
>
> That would insure complete backcompat regarding 'errstr', and might also be
> part of the solution to "make errors fatal", perhaps by pairing it with an
> "auto_throw" option:
>
> Imager->new( auto_throw_exceptions => 1 );
>
> Someone who wanted this behavior throughout a large project could sub-class
> Imager and set "auto_throw_exceptions" as a default.
Maybe I'd add an error() method that returns an object with the error
type (usage, corrupt image, I/O) and the components that make up the
error message. Something like:
# example reading a truncated GIF image
{
type => "CORRUPT", # or USAGE, IO (?), others?
errors => [
[ 0, "IO", "Failed to read from file" ],
[ 0, "CORRUPT", "Unable to get image descriptor" ]
]
}
(as an object with appropriate methods)
Of course, doing this is a lot of work, I'd need an alternate set of
i_push_error*() functions in the C parts of Imager that accept an
error category as well as the code and message text.
Show quoted text> (Like the original idea, I would suggest that "throw" object of type
> Imager::Exception or Imager::Exception::Corrupt based on the type of
> error).
>
> What do you think?
My original idea was something along the lines of autodie, so *any*
failure would cause an exception, complicated by some methods
internally (harmlessly) producing errors which don't need to be
returned to the caller (and hence shouldn't produce an exception.)
Your idea is good in that it adds error categories but that's only
loosely related to to "throw an exception on error".
Basing the error category on the error message (as your sample does)
is evil and broken and won't be implemented.
How is your "auto_throw_exception" option intended to work with
different categories - does it onlt throw on USAGE errors, or all
errors?
Tony
