Juicy.Pixels icon indicating copy to clipboard operation
Juicy.Pixels copied to clipboard

Better error reporting

Open mpickering opened this issue 10 years ago • 3 comments

Firstly - thanks for the library.

The suggestion: rather than return Either String DynamicImage it would be better to have a custom data type for errors so that users could more accurately handle exceptions. This would also document what sort of exceptions can be thrown.

For example you could have a new data type

JPError = EncodeError String | DecodeError String | ...

and the signature would then be Either JPError DynamicImage

I can implement this if this kind of patch would be welcomed. If so, some guidance about the kinds of errors you would like to report would be appreciated.

mpickering avatar Aug 12 '14 12:08 mpickering

An EncodeError is highly unlikely to happen, for the kind of DecodeError, it's a case by case analysis and highly dependent on the image format being decoded. The real question would be, what kind of precise error would the user need, and I'm not sure it can do anything with it :-/ . And some times, the only error which can be reported is "the image is borked"

Twinside avatar Aug 12 '14 14:08 Twinside

Like I said, I'm not familar with the internals so I can't comment what kinds of errors are likely to happen. I guess my point is that using the API I might want to handle some kinds of errors differently but at the moment I don't even know if I can as it is not clear what the different kinds of errors that the library can throw are.

Even a simple type data JPError = DecodeError String would be better I think as I then know there's nothing useful I can do with the error message without looking at the source.

mpickering avatar Aug 12 '14 14:08 mpickering

Ok, it's worth a shot. If you can try something, I'd be glad to look about the integration.

Keep in mind backward compatibility if possible

Twinside avatar Aug 13 '14 07:08 Twinside