Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^2: Style guide for error messages?

by xdg (Monsignor)
on Sep 21, 2005 at 23:25 UTC ( #493996=note: print w/replies, xml ) Need Help??


in reply to Re: Style guide for error messages?
in thread Style guide for error messages?

I agree on objects being the thing the throw. (c.f. Exception::Class and my own Exception::Class::TryCatch)

However, even the object carries with it some message that may wind up in front of the user. But if I understand your argument, you're suggesting never bothering to add any error string at the time of the croak -- just the default system output -- and using the description defined in the Exception::Class object as the message instead. That does just push the problem upstream, as it were, but at least it's done only once, and at a time when more thought can be devoted to crafting the message (and it can be parameterized with fields as necessary). That's a good idea. ++

On the other hand, I think it requires overriding the as_string function to stringify as the description plus the right field(s) in case it isn't caught. Lots of up front work, but on a large project, definitely less headache in the long run. E.g., a very brief, quick example:

use Exception::Class ( 'FileOpenError' => { isa => 'Exception::Class::Base', description => "Error: couldn't open the file called ", fields => [ 'filename' ], alias => 'throw_file_open_error', }, ); BEGIN { # minimal stringification *FileOpenError::as_string = sub { my $self = shift; return $self->description() . $self->filename(); } } # later... open my $fh, "<", $filename or throw_file_open_error( filename => $filename );

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://493996]
help
Chatterbox?
[oiskuu]: glibc getlogin just does ttyname() and falls back on getutline(); it's not security related at all. (reminds me of sendmail and remote finger services of the naive early spam era)
[Corion]: But yes, "who started this process" is interesting information :)
[tye]: no, I really believe that "login user" was added as a fundamental bit of info about each process in order to enhance the usefulness of auditing
[Corion]: Ah - if that information is saved in a file, then you could theoretically spam that file and confuse getlogin(). So, don't use it for authentication :)
[tye]: that is what getlogin() certainly *used* to do. I don't believe that is what it certainly should do.
[davido]: /var/run/utmp is 664 i think.
[tye]: Note that my "man getlogin" says that it uses stdin when it should use /dev/tty (calling a glibc bug). But that does not appear to be the case when I test it. But maybe Perl's getlogin() is not using glibc's getlogin().
[oiskuu]: well, run a strace and see what the getlogin does for you.... As I said. SELinux probably has those security labels. But not regular linux.
[tye]: for example, read https://unix. stackexchange.com/ questions/146138/ loginuid-should-be -allowed-to-change -or-not-mutable-or -not
[tye]: I'm not using SELinux and it certainly appears to disagree with you. shrug

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (9)
As of 2017-06-23 19:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How many monitors do you use while coding?















    Results (554 votes). Check out past polls.