My 2 cents is: This is a good example of why I like to use promise based async code. You promise to do something, and then there is a call back for either having done it (which can be passed a result), or another for having failed to do it (which can be passed an error message). And thus the two paths (success or failure) can bubble up as far as necessary by parent promises and so on.
In this case its somewhat different because CGI code is meant to execute synchronously: do a particular job, and then finish, passing back a result. So what you are doing is fine: Always return and let the user check the result. They key part is really the 'always return' part - you need to make sure your interface is clear to the end user. One of my biggest gripes about Perl modules in general is that most modules simply throw exceptions because they almost seem to except Perl to be being used at a console by a user executing something synchronously. You have to wrap practically every module in an EVAL statement if you want to make useful web code that is able to handle any error conditions gracefully instead of just crapping itself.
In reply to Re: Error handling in a module
by Anonymous Monk
in thread Error handling in a module
by Bod
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |