This seems more like a way of presenting an error to the user than an error itself; that is, I don't really see a potential is-a relationship to Error. Instead, I'd use this code as a way to translate an Error object into user-readable form.

Since there's obviously a lot of code missing, I have to speculate here, but it looks to me like the module is responsible for both controlling login behavior and displaying errors to the users. More ideally, these two pieces of functionality would be decoupled, preferably into separate modules but you could get away with keeping them separate within one. To use Error, I'd envision that the part of the module that does the real work of login validation (i.e., sanity checking the password, comparing it to an encrypted version in the DB, etc.) would raise an exception appropriate to the error condition encountered. The exception would contain the error string to be returned to the user. For example, you might have an exception hierarchy like so:

    Error
      | # arrow indicates an inheritance relation.
      V
     LoginError
     |         |
     V         V
LoginBlocked  PasswordError
              |             \
              V              V
              PasswordBlank  PasswordInvalid
[download]

And you'd indicate that an error has occurred with code like throw PasswordInvalid("PasswordNotFound\n") unless ($some_test_here);

Your calling code, presumably a CGI, would contain code something like this (way oversimplified) example:

my $error_msg;
try {
    GateKeeper->validate($username, $password);
} catch LoginError with {
    my $ex = shift;
    $error_msg = GateKeeper->format_error($ex->{-text});
    # Or better, SpecialFormatModule->format_error($ex->{-text});
}
[download]

Basically, you would trap exceptions raised by your validation code in GateKeeper, and then (taking seattlejohn's excellent advice), run that string through some formatting code so you don't have to worry about mixing HTML into your error messages.

Next you'd check if $error_msg was defined, and if so you'd know that something bad had happened. You wouldn't need to figure out what though, or do any more work, because you'd already have all the formatting done. Just print the page.

1. For more robust exception handling you'd have the option of catching more specific subclasses rather than simply the lowest common denominator for any exception you expect to encounter here (e.g., LoginError). But for simplicity's sake...