On Fri, Sep 30, 2005 at 18:02:46 +0200, TSa wrote: > I knew that the statement would emotionalize. Sorry to all who don't > like it an this list. But somehow I found it describes the impression > on the handling side somewhat. And I thought it illustrates that exceptions > shouldn't be considered just another tool.
I think you're taking it too seriously. I'm 99% sure Piers was
joking.
Regardless, exceptions *are* just another tool. They let you write
safe code in fewer words and with less distraction.
For example, Either you linearly serialize the entire tree of
possible events:
if (my $handle = open "file") {
# the handle is open
if (my $other_file = open "other" :w) {
for =<$handle> -> $line {
unless ($other_file.print($line)) {
$*ERR.print("other could not be written
to: $!"); # disk might be full
if (close $other_file) {
if (close $handle) {
exit 1;
} else { ...; exit 1 }
} else { ...; exit 1 }
}
exit 0;
}
} else {
$*ERR.print("could not open other for writing: $!");
if (close $handle) {
exit 0;
} else {
$*ERR.print("could not close file: $!"); # not
logical,
# since we don't write to file, but this is
"safer"
exit 1;
}
}
} else {
print $*ERR, "could not open file: $!";
exit 1;
}
or you could throw exceptions:
use fatal;
my $handle = open "file";
my $other_file = open "other" :w;
for =<$handle> -> $line {
$other_file.print($line);
}
If you are going to avoid exceptions because they are too much
<something> for your taste, then I think you are misusing a language
that has support for exceptions.
I really don't understand why this has to do with freedom, or it's
restriction. It's your personal (and IMHO bad) taste not to use
exceptions for improving your code, but it's still your choice.
All I was saying is that you could leverage exceptions by letting
the UI code make the handling of exceptions a two way route, instead
of one way.
> > CATCH Exception { say "Why do you hate freedom?" }
>
> I don't. But the freedom of the individual ends where the
> community begins.
I think this is a big exaggeration. The community will not be harmed
if the individual uses exceptions.
On the contrary, i would be much happier to use code that does
through exceptions.
For example, a very useful perl 5 module, UNIVERSAL::require, lets
me write:
$class->require or die $UNIVERSAL::require::ERROR;
instead of
eval "require $class"; die $@ if $@;
but in both cases I have to check for errors, unlike
require Class;
I still prefer $class->require, though, because it feels more
readable to me. I don't say to myself "wtf? why is this code doing
an eval" while reading the code.
In perl 6, we would ideally have:
use fatal;
$class.require; # lives if class exists, dies if class doesn't exist
$class.method; # always lives (if method really exists)
or
use fatal;
try { $class.require } # always lives
$class.method; # might die, but at least it's obvious
or
no fatal;
$class.require; # always lives\
$class.method; # might die
In fact UNIVERSAL::require's author agrees with me:
http://use.perl.org/~schwern/journal/26939
Now, if this were
#!/usr/bin/perl
use fatal;
use Pluginish::App;
sub &infix:<s~> ($l, $r) { "$l $r" }; # spacey concatenator
{
Pluginish::App->load_plugins;
CATCH {
when Module::load_error {
if (prompt("The module $!.module_name could not
be loaded because"
s~ "an error occurred ($!). Try to
continue anyway?") {
$!.resume(undef);
} else {
die $!;
}
}
}
Pluginish::App->run;
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /methinks long and hard, and runs away: neeyah!!!
pgpxShOEewGd9.pgp
Description: PGP signature
