The value of the change (positive/negative) determined the direction of the change and based on that a css style which is used to colour the message.
First observation, if the only purpose of the parsing is to detect positive or negative--the regex was wrong. A simple $message =~ /-/ would probably suffice, and create parity with your exception solution in as much as you could change the datatype of the value without requiring a change in the exception handling mechanism.
Not that I would advocate that solution, but it demonstrates the contrivance of your example. It conflates two exceptions as one.
The correct solution for the problem of two different possible errors, is to raise the appropriate of two exceptions. One for less; one for more. Each with a different error number. Then there is no purpose in parsing the error; a simple compare takes the appropriate action.
I would like to ask you to look at the original starting post
Out of courtesy, I looked again. And I reached the same conclusions.
Nothing in the OP requires, nor would benefit from, a structured exception. What corrective action could be taken to correct a failure to retrieve a file? None!
The only possible action is to report the error and terminate. Whether it be that the file does not exist;, or has the wrong permission; there is no point in trapping the die, when the only reasonable action is to do exactly what die does. And all to satisfy the scurrilous default from perl-critic.
Recommending moving to using E::C, in order to silence perl-critic, when the only possible action is to (laboriously) emulate exactly what die does, is ...
(*)Did you do me the courtesy re-reading each evolution of my posts, within the context of the posts to which I replied? (Betting not!)
-
-
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| 