It sounds like it's time to move from simple error strings to exception objects. I like to use Exception::Class. Then you can do stuff like

  eval {
      my $obj= ObjClass::Obj->new();
            $obj->id( $id );
            $obj->load_via_id() ;
            $res= $obj->id ;
            Exception::ActivatedAccount->throw 
               unless $obj->activated_account;
  };

  if( my $e = Exception::Class->caught ) { 
       # handle exception and decide about logging here
  }
[download]

You can put any data you like into the exception object, including diagnostic messages and a flag which indicates whether or not to log it. Because you can create them in class hierarchies, you can make relatively clean exception handling code by checking if the exception object isa something you can deal with, and rethrowing it if it's not.

eval {
    open my $thingy, "something" or die $!;
    die "something\n" if $something;
};

if( $@ ) {
    if( $@ eq "something\n" ) {
        # logging here

    } else {
        die $@;
    }
}
[download]

I actually got that from the alarm(3) manpage, so don't hold it against me.

In addition to responses above me (which all point you in the direction you probably want to go in), I'd like to tell you something interesting about the behaviour of die I recently discovered.

This behaviour is documented in the description of die. Allow me to quote.

die LIST
... Inside an eval(), the error message is stuffed into $@ and the eval is terminated with the undefined value. This makes die the way to raise an exception.
...
If the last element of LIST does not end in a newline, the current script line number and input line number
...
(paraphrased: "input line number" means whatever the current value of $/ is. Usually just \n, though.)

Good. Now the underlined part is important there. It implies that if you include $/ at the end of your die message, you can prevent the at line X of Y to be added to the die message. That raises an interesting use of die. Let's see.

my $codeblock = "Important and unimportant stuff";
eval {
    doImportantStuff;
    #if anything goes wrong, it goes `die "invalid important stuff\n";
+`
    #This should be logged

    doUnimportantStuff;
    # `die "invalid unimportant stuff\n";`
    # Should not be logged.
    
    moreImportantStuff;
    #`die "more invalid important stuff\n";`
    # Should be logged
};

log_error("$@", $codeblock) if $@;


sub log_error {
    return unless DEBUG;
    my $error = shift @_;
    my $place = shift @_;

    my @logthese = (
        "invalid important stuff\n",
        "more invalid important stuff\n",
    );

    for my $check (@logthese) {
        if ($error eq "$check") {
            write_to_log("Error '$error' at $place");
            last;  # found! No need to continue searching
        }
    }      
}
[download]

Code is only intended to illustrate a point and therefore untested. Use at own discretion.

Update: spotted a stupidity in the code, fixed that.

warn works the same way (w.r.t. newlines and line numbers.)

For one reason or another, I didn't know that yet. However, it suprises me neither :)

see also http://perlmonks.org/?node_id=537806 for a regex to 'clean' the line number from die. personally, I use a constant/var to toggle whether or not i want line numbers to be shown ( show on dev, hide on prod )

log_error( "$@" );
[download]

... Ofcourse, $@ gets stringafied here, so if it is an Exception object (or, if you want to be perverse, a hashref) it'll get magled, with differing degress of success. (Although most exceptions stringify nicely, so that you can read if they're uncaught, and reach your terminal.)

perhaps log_error( my $something_else = $@ ) to copy it? ...

@_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;

sub check_id {
  my ( $id )= @_;
  my $res;
  eval {
      my $obj= ObjClass::Obj->new();
            $obj->id( $id );
            $obj->load_via_id() ;
            $res= $obj->id ;
            if (! $obj->activated_account) {
                DEBUG && warn "invalid user";
                return -1;
            }
  }
  if ($@) {
     DEBUG && log_error( $@ );
     return -1;
  }
  return $res;
}
[download]

Slightly more generally, you could allow multiple of these eval blocks in a single routine with (excuse the funny indentation):

sub check_id {
  my ( $id )= @_;
  my $res;
  eval { {
      my $obj= ObjClass::Obj->new();
      $obj->id( $id );
      $obj->load_via_id() ;
      if (! $obj->activated_account) {
          warn "invalid user"; # or not...
          $res = -1;
          last;
      }
      $res= $obj->id ;
  } }
  if ($@) {
     DEBUG && log_error( $@ );
     return -1;
  }
  return $res;
}
[download]

Your return values seem a little odd, though. This routine can return three things: undef, -1, or a valid id, where -1 seems to mean either an expected or unexpected error and undef means... well, I don't know. There must be some reason why you're doing $res = $obj->id. Is there some reason why it might not return a valid id, other than the activated_account test failing? If not, then why not just set $res to -1 if activated_account fails? Why throw an exception at all if it isn't really an exceptional case? If there is some subset of cases where an undef return value is meaningful, then it seems like the caller of this function has to do too much work to decipher all the possible things the return value might mean.

sub check_id {
   [...]
   eval {
      my sig_die_handler = sub { ... };
      local $SIG{__DIE__} = \&sig_die_handler(shift);
      [...]
   }
}
[download]