Abstracted away some error messages

[skaurus]

Hi.

This is done to help folks catch exceptions from this module and to be more error prone to module updates.

Why have I abstracted only these ones? I've chosen errors that may arise unexpectedly, at random times and not as a result of programmer errors. Most others should be fixed by changing client code once instead of trapping inside eval, and rest are fatal enough for catch-all logic (no need to catch them individually because we can't fix it - everything just broke too hard). IMHO.

[vsespb]

+1

Q1: Why not use 'use constant' ? Q2: Why not export this constants ?

[skaurus]

A1: As far as I know, there are no significant differences between subs and constants, so it could be changed either way. A2: Actually I initially wrote the code using @EXPORT_OK and %EXPORT_TAGS, but then I decided that then I should add REDIS_ prefixes to the subs names - current subs names are too generic for exporting. Not that they are likely to collide with anything, but someone reading client code will not guess where they came from at first sight. And then it's just no shorter than writing Redis:: instead. And, well, this way it's one dependency less. But I have no serious objections here too.

[skaurus]

Also I just thought maybe these subs/constants should be moved down, after all the use's? Current position made sense while I was using Exporter approach.

[melo]

Maybe we should just use object as exceptions?

[skaurus]

Sure. Something like this?

die bless(\$m, 'Redis::X::Reconnect::Transaction')
die bless(\$m, 'Redis::X::Reconnect::Watch')
die bless(\$m, 'Redis::X::Reconnect::ResponsesPending')