note
daxim
The underlying question here is how should abnormal situations (server responses) be handled. It's tricky. Because Perl is flexible and does not prescribe much dogma, prefers to provide [http://ddg.gg/%22mechanism%20not%20policy%22|mechanism over policy], you might ask three programmers and get five opinions.
<p>
After looking at your module's code, here's mine. I subscribe to the school of thought that says that exceptions should be for exceptional circumstances, and a server returning an error within its protocol falls under normal operation. I also think that stuffing useful information into a side-channel (like warnings or a special error attribute that needs to be checked each time) is a smell, and shifts into the territory of bad code when the methods' regular return value is merely an anaemic boolean. A counter-example of rich return values is [mod://ReturnValue].
<p>
The following also applies to your code in special and is tangentially relevant:
<ul>
<li>Stringly typed warnings and exceptions are outright bad because they are difficult to reuse, couple way too tightly (fix a typo? you just broke the API…) and require parsing to get at information – use objects instead. I like [mod://failures] because it's very light-weight and throwing is not required, so the object can easily be used in a different way, e.g. for warnings or [mod://Data::Monad::Either|monadic error handling].
<li>The API is not fully documented, diagnostics are missing – see [https://metacpan.org/release/Module-Starter-PBP/source/lib/Module/Starter/PBP.pm#L662|M::S::PBP] for a template.
</ul>
<hr>
If you decide to keep the code mostly as it is, look into registering warnings categories. That allows the user to selectively fatalise warnings and you don't need to mess with a instance-global autodie flag.
<p>
That was all rather theoretic and vague. If I have some time today, I would sketch out some real code for W::D::W. Is there a public test server I can use?
11107229
11107229