use fatal err fail

Basically, my observation is that no-one consistently checks the return values of
the built-in functions. As Mama[1] can attest, lots and lots of code is posted to
Perl Monks calling open without checking the return value. Even among those who
check the return value of open, just about none check for close[2]. And have you
*ever* seen a program that actually checks the return value of print[3]?

Exception handling seems to provide a good solution to this. Instead of writing
"open ... or die ..." every time, we can just blindly assume the open worked, and
catch the error later. If we don't catch it, it does exactly what the "die" would
have anyway, so we're no worse off. The exception propagates upwards until it's
handled, or it terminates the program. At least the program doesn't continue
blindly, believing all to be well. The problem with typical exception handling
code is that it quickly becomes bulky and ugly. Compare.

#ignore any files we don't have access to
for @files {
my $fh = open $_ or next;
load_config_from($fh);
}

with

#ignore any files we don't have access to
for @files {
my $fh;
try {
$fh = open $_;

CATCH {
next;
}
}
load_config_from($fh);
}

So returning a special value makes checking the return code simpler, but hurts us
if we forget. Throwing an exception saves us from forgetting, but has the
nastiness of catching that exception.

I propose that the spelled out version of // be renamed to something like "dor".
(I'm willing to accept other suggestions on that.) "err" becomes a
single-expression level try/CATCH block. The left hand side is executed, and if it
successfully returns anything (even undef), it's value is used. If it throws an
exception, however, that exception is caught and the right hand side is evaluated
and used. So that code becomes

for @files {
my $fh = open $_ err next;
load_config_from($fh);
}

which is just syntactic sugar for

for @files {
my $fh = try {
open $_;

CATCH {
next;
}
}
}

"err" would bind tighter than assignment, so it can be used to provide a fall-back
value to use in case the normal flow of control fails. Using "no fatal" is still
allowed, but you can achieve almost the same thing [4] by adding "err $! but undef"
after calls whose failure you want to handle that way.

I think on the whole this gives us a way to allow exceptions to be used everywhere,
while making it clean and simple enough that it doesn't bog us down too much.

[1] http://www.perl.com/pub/a/2005/09/22/onion.html?page=6
[2] I've actually seen data lost due to this. When drive space is very limited
(due to, for instance, a user quota) it's often possible to open a new file (since
there's some space left), but the close fails since too much was written to it.
[3] Actually, I'm not sure this is fair. It seems that, due to buffering and other
things, print returns true even when it doesn't actually succeed. But why let
facts get in the way of rhetoric?
[4] The difference is that "no fatal" would only affect code that calls "fail"
itself. The "err" would affect code that directly calls "die", too.
--
Adam Lopresto
http://cec.wustl.edu/~adam/

Eschew obfuscation!

I like it a lot. It gives the advantages of both the flexible, more
robust try/catch, and the (locally) concise, clear error return.

The only problem I see is that most people (i don't know why) argue
that 'use fatal' should be off by default.

Your proposal still makes a lot of sense even if 'use fatal' is
optional, though.

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me climbs a brick wall with his fingers: neeyah!

I totally, TOTALLY, agree with this.

EVERY built-in function and operator that talks to program-external
resources should by default throw an exception on failure, including
all system calls, file or filesystem operations, network operations,
interprocess communications, signals, etc.

It is a lot easier to write safe, correctly functioning, and easy to
debug programs when problems are detected as early as possible, which
a default-active exception architecture ensures.

Naive developers will be helped greatly when they forget to account
for possible problems, since errors don't crop up in a different
place than their cause (eg, at 'print' time when the problem was with
the 'open'); if they forget something, Perl will tell them.

Saavy developers who don't like the exceptions can explicitly turn
them off, the very act of which implies that they know what they're
doing and can handle the situations where Perl doesn't help them
remember.

Considering that its a well known best practice to throw exceptions
in one's own non-trivial programs and modules, it would be nice if
the core language functions themselves were consistent with that
practice.

Just as I agree that having 'use strict' turned on all the time
and/or being the default, likewise having 'use fatal' turned on all
the time and/or by default is also the best course of action. While
we're at it, 'use warnings' should probably be on by default too, but
this is less important than 'fatal'.

-- Darren Duncan

I don't like it at all. I fear, that we mix two orthogonal concepts
just because it is convenient.

To me the statement

return 42; # 1

has to orthogonal meanings:

1) the current scope has reached its (happy) end
2) a specific result was determined

We can vary on both of these dimensions *independently*!
Which gives the remaining three cases:

return undef; # 0 unspecific result
fail undef; # -1 no return with unspecific reason
fail 42; # -2 no return but determined reason

In other words an exception means

return !caller;

or in yet another way to describe my attitude: the least
thing that *defines* an exception is that the dynamic
scope in question has reached the conclusion that it
is *not* going to give control back to its creator!

Note that this somewhat pinpoints or controls the two infinities
of computing in time and storage. One either needs a block of infinite
length right away or handle control flow exceptions *on the outside*
to keep a finite scope going.
--
$TSa.greeting := "HaloO"; # mind the echo!

"just because it is convenient" is precicely why I like it =)

return literally means "give back". The caller is getting a value
that we give. This implies two completely non-orthogonal meanings to
me:

1) the scope has reached its happy end
2) it's reached the end because a specific result was determined

just 'return' would do. But This is odd, unless the context is void
- if the caller is expecting something, wer're not returning an
"unspecific result" - we're returning a value. This value is in
bounds (it's a normal perl scalar) and it has a well known meaning
that "i have have nothing meaning to report".

I think this is actually a very concrete result.

Fail is, semantically:

(should_die ?? die !! return)

and the caller gets to determine the behavior.

Whether failures have an extras payload in a simple return
value, or whether the payload is carried via an out of bounds route
to the closest thing that can handle is really only dependant on how
the caller is most comfortable with handling errors.

Not at all!

It's simply returning an out of bounds value to the closest caller
that is willing to handle out of bounds values.

In fact, it's short circuiting to it's caller, to give it control as
fast as possible since it doesn't know what to do anymore.

The reason exceptions tend to pop upwards more is that they are
handled in a way that if the immediate caller doesn't know how to
handle it either, it keeps going up the call stack till a calling
scope does know what to do, and can explcititly take control.

/\ kung foo master: /me beats up some cheese: neeyah!!!!!!!!!!!!!!!!!

I agree with you, TSa. I'd like to add that we don't have to do without
convenience in the majority of cases:

use fatal;

for @files {
my $fh = try { open $_ } err next;

load_config_from($fh);
}

* try {...} is, like Perl 5's eval {...}, *not* statement-level.
This means you can easily wrap it around an expression.
Particularly you can write
my $fh = try { open $_ } err next; # instead of

* Yes, "try {...} err ..." does not check the exception type, but
the proposed "... err ..." doesn't either.

* "try { foo() } err next" will next even if foo() did not throw
an exception, but returned undef. But I don't think that's a problem
in most cases. One can always do:
try { foo(); 1 }

FWIW, I also agree with Darren that "use fatal" should be on by default.

--Ingo

I think that's a flag that it's not a great idea.

For the example given, I'd rather write
my $fh = try {open $_; CATCH {next} };

and still fit it on 1 line!

For what it's worth, I'd like to chime in on 'yes please' for having
fatals on by default.
I've been hanging round some perl forums lately, and it's such a
basic, recurrent issue.

Cheers,
Carl

You already know that "err" is the low-precedence version of //, right?
What replaces that? I like "default" or "defaults" myself, but I'm never
really sure what the precedence actually IS. After all, "and"/"or" were
lower than assignment, so you could code:

$a = foo or die;

and get ($a or die). How does this work for the "err"/"defaults"
keyword? Does the low-precedence version move up, or is there an idiom I
don't understand?

On the primary hand, I don't like the idea of using "err" as a try/catch
because that's putting exception handling in line with the primary code.
See FMTYEWT below.

But it *does* give control, albeit briefly, back to its caller.

A million years ago, $Larry pointed out that when we were able to use
'is just a' classifications on P6 concepts, it indicated that we were
making good forward progress. In that vein, let me propose that:

* Exception handling, and the whole try/catch thing, IS JUST An awkward
implementation of (late! binding) run-time return-type MMD.

Specifically, if I promise you:

sub foo() will return Dog;

and later on I actually wind up giving you:

sub foo() will return Exception::Math::DivisionByZero;

the try/catch paradigm essentially says:

I wanted to call <c>sub Dog foo()</c> but there may be times when I
discover, after making the call, that I really needed to call an anonymous
<c>sub { $inner::= sub Exception foo(); $e = $inner(); given $e {...} }</c>.

We're conditionally editing the return stack. This fits right in with
the earlier thread about conditionally removing code from the inside of
loops, IMO. Once you open this can, you might as well eat more than one
worm. Another conceptually similar notion is that of AUTOLOAD. As a perl
coder, I don't EVER want to write

say "Hello, world"
or die "Write to stdout failed.";

-- it's "correct". It's "safe coding". And it's stupid for a whole bunch
of reasons, mostly involving the word "yucky". But I acknowledge that
through the miracle of broken pipes, it can legitimately happen that
stdout will fail while stderr is a viable diagnostic mechanism.

Instead, I want PERL to fill that in for me: I believe that the default
error mechanism should debug my program, the shell script that calls my
program, and the actions (including blood alcohol content) of the user
of my program over the last 24 hours: lets leave <c>use autodebug;</c>
turned on by default.

The 'Exceptuation' proposal seems to me to include two things:

1. A 'RESUME' feature.
2. An implicit acknowledgement that the default implementations are
parallel:

{...
CATCH -> $e {throw $e;} # Going up?
RESUME -> $r {resume $r;} # Going down?
}

The rest is optimization. If caller() includes an array of
continuations, then <c>throw</c> looks like a loop up the array:

sub throw(Exception $e)
{
reverse caller() ==> { .continuation($! => $e) if does(CATCH); }
}

But the default behavior (modulo threads) is going to unlink all the
stack frame pages when the continuation is invoked. So there has to be
yet another copy of the links to the stack, because the exception
handling will want to call functions and build who-knows-what elaborate
skycastles. And it must be reentrant because of the possibility of
exceptions during the exception handling. Which means that the call
stack needs to be stored in the Exception. [The list of things in the
exception gets pretty long. I'm sure it's all a ref to the last page of
the call stack, so it doesn't gobble up much space, but there's a lot of
"and you'll want"s coming up.]

So <c>resume</c> is a multi, no? (Or it could just be a method:
$!.resume, but that doesn't read as well in a block that *really* should
be as readable as possible.) Also, any layer of exception handling may
do some nontrivial amount of work before encountering its own exception:

{
...
CATCH -> $e
{
do_some_work; # exception in here?
do_more_work; # Or in here?
resume $e;
}
}

Which kind of argues that either (A) very fine control of RESUME blocks
must be available:

{...
CATCH -> $e
{
do_some_work;
RESUME {...}
do_more_work;
RESUME {...}
}
}

or that (B) very fine identification of exceptions be available,
*including from the p6 library*. Perhaps typed resumptions are as
important as typed exceptions?

sub copy_file($from, $to)
{
...
RESUME -> $r
{
when Resumption::Microsoft::AbortRetryFail::Abort { last; }
when Resumption::Microsoft::AbortRetryFail::Retry { continue; }
when Resumption::Microsoft::AbortRetryFail::Fail { return FAILED; }
}
}

I don't actually like this, because I don't like the whole notion of
upper-case blocks: it's stuff that the really good perl IDE is going to
hide so that the "real" code shows through.

Also, of course, there's the question of leverage: throwing an exception
is a way of quickly saying "something happened outside the expected".
One enormous benefit of $perl[1..5] was that the exceptions were
huffmanized really highly: <c>die</c>. This was good not because
exceptions were common, but because they were uncommon, and allocating a
short token allowed the reader to bypass them quickly. The whole "or die
message" idiom worked for that reason:

if (print("Hello, world!") == -1)
{
print STDERR "Could not write greeting message";
exit 1;
}

vs.

print "Hello, world"
or die "Could not write greeting message";

I think that moving the <c>die</c> into <c>print</c> is a win, but it
disconnects the diagnostic a little bit:

print "Hello, "
or die "Could not write first part";
print "world!\n"
or die "Could not write second part";

Becomes a single generic failure message thrown by:

print "Hello, ";
print "world!\n";

Abstractly, you want the generic-ness, but simultaneously want to think
that someone can catch these errors at the relevant place and quickly
tailor them. The right place, of course, is the sub or method that is
doing the work. I want to be able to CATCH local exceptions locally,
too! Not because "I don't know what to do", but in a more Knuth/literate
sense, I don't want to write about what to do in-line with my beautiful
algorithm:

sub greet
{
print "Hello, " # or throw PrintException;
print "world\n" # or throw PrintException;

CATCH
{
when PrintException {...}
}
}

But I want to know which PART of my elaborate greeting failed. In the p5
version I could discriminate between first-part failure and second-part
failures. Why has p6 backslid into mealy-mouthed genericity?

One way, Yuval's suggestion, is to make "err" be a quicky catch mechanism:

sub greet
{
print "Hello, " err die "Could not write first part";
print "world!\n" err die "Could not write second part";
}

But that's not abstracting anything. It just keeps the same, tedious,
check-every-result coding layout and gives it fractionally worse
Huffmanization. What I want is to catch my errors elsewhere, and still
be able to localize their solution. Cleverly, there's already a way to
do this: labels. All I need is to know where I'm at, label-wise, and
I've got a dandy way to mark my code up.

sub greet
{
FirstPart:
print "Hello, ";

SecondPart:
print "world!\n" ;

CATCH
{
when PrintException
{
fprintf(STDERR, "Could not write %s part",
caller.label.tolower.s/part$//);
}
}
}

This is a little more important than it seems, because for resumptions
it will likely be important to know what work has been done. Likewise,
any and all kinds of error handlers will want to know about resources
that are allocated but need to be put back. The <c>finally</c> block is
the ultimate admission of failure in this regard:

[quote=http://java.sun.com/docs/books/tutorial/essential/exceptions/finally.html]
The final step in setting up an exception handler is to clean up before
allowing control to be passed to a different part of the program. You do
this by enclosing the clean up code within a |finally| block. The
|finally| block is optional and provides a mechanism to clean up
regardless of what happens within the |try| block. Use the |finally|
block to close files or to release other system resources.
[/quote]

But resumptions are going to let us FIX the problem that occurred when
we tried to open the 256th filehandle. So all the directory parsing,
file exploring, and whatnot is going to be *preserved*. Thus we don't
actually want to automatically finalize all that stuff unless we know
for sure that we aren't going to resume: even *later* binding. If there
were a FINALLY clause (let us pray for deliverance, here, banjos and
all) it couldn't be run until a CATCH block exited.

In the meantime, we're trying to resume from exception handling. So like
the gynecologist who changed jobs to become a motorcycle mechanic, we
want to do all our work by reaching through the tailpipe. The exception
[here we go again] needs to bundle along a stack that provides access to
the variable scope. Yet another use for a Pascal's <c>with</c> keyword:

# NB: Testing new MySql 5 server
BEGIN
{
CATCH -> $e
{
when Exception::Database::Mysql::Connect
{
with $e.namespace
{
if $dsn ~~ 'mysql:'
{
$dsn.s/^mysql:/mysql5:/;
$e.resume;
}
}
}
}
}

=Austin

Yes, he proposed 'dor'.

As I see it err is like this:

sub infix:<err> ($lhs is delayed, $rhs is delayed) { # we really need thunk parameters
return $lhs dor $rhs;
CATCH { return $rhs }
}

So really 'err' is just 'dor' with an added error silencer.

Isn't

no fatal;

my $fh = open $file or die;
...
my $fh = open $file or next;

also putting exception handling in line with the primary code?

Isn't that useful?

Exception handling should be put in wherever there is well defined
behavior on how error conditions should be dealt with.

It's Perl's job to make this as easy as possible for the programmer.

If we have a module called File::Slurp::Some, which doesn't really
care if some of the files don't exist, it's code would, IMHO be
much more readable with

open $file err next;

than a catch block.

The reason for this is that a catch block is always detached from
the code.

However, if the error is part of the normal flow (it is no longer
exceptional for the file to not exist), what benefit does the added
detachment give?

Exception handling is just continuation passing style with sugar.

Have a look at haskell's either monad. It has two familiar keywords
- return and fail.

Every statement in a monadic action in haskell is sequenced by using
the monadic bind operator.

The implementation of >>=, the monadic bind operator, on the Either
type is one that first check to see if the left statement has
failed. If it does, it returns it. If it doesn't it returns the
evaluation of the right hand statement.

Essentially this is the same thing, just formalized into a type....

In haskell:

foo :: Either Dog Exception::Math::DivisionByZero

e.g., it can return either the expected type, or the parameter.

Haskell is elegant in that it compromises nothing for soundness, to
respect referential integrity and purity, but it still makes thing
convenient for the programmer using things such as monads

Yes and no.

The try/catch mechanism is not like the haskell way, since it is
purposefully ad-hoc. It serves to fix a case by case basis of out
of bounds values. Haskell forbids out of bound values, but in most
programming languages we have them to make things simpler for the
maintenance programmer.

It's incorrect because it's distracting and tedious.

http://c2.com/cgi/wiki?IntentionNotAlgorithm

Code which does it is, IMHO bad code because obviously the author
does not know where to draw the line and say this is good enough,
anything more would only make it worse.

the default $SIG{PIPE} handler is a wonderful example of how nice
exception handling is for naive code.

$SIG{PIPE}'s only problem is that it's completely non standard.

Forget the stack... Perl is CPS under the hood, even if it's
optimized not to be that way.

Reentrancy is an implementation detail best left unmentioned.

Assume that every bit of code you can run in perl 6 is first class
code - it gets safety, calls, control flow, exceptions, and so
forth.

Yes, even signals and exceptions.

The runtime is responsible for making these as fast as possible
without being unsafe.

The .resume continuation in the exception is equivalent to the call
stack, as is any other continuation, implicit or explicit.

Yadda yadda, static analysis could solve this.

A one liner with no catch blocks whatsoever could be implemented
without CPS at all, and this can be determined at compile time
pretty easily.

It can't be a method because it never returns to it's caller - it's
a continuation because it picks up where the exception was thrown,
and returns not to the code which continued it, but to the code that
would have been returned to if there was no exception.

It is, IMHO a multi though. There is no reason that every
continuation cannot be a multi, because a continuation is just a
sub.

I don't know if there are method continuations - i guess there could
be, but there's no need to permutate all the options when the
options can compose just as well.

That's OK.

just assume they work inside out when being resolved. This is just
recursion into an alternative control flow, which is then stepped
out of if there were as many .resumes as exceptions were thrown.
There is no fundamental difference between exceptions and normal
code once you accept continuations.

I don't understand this at all.

What does it mean? what exception is it?

I think maybe this is what you wanted:

{
error_throwing_code;
CATCH {
do_some_work;
CATCH {
# the exception raised in the exception handler is
# caught here
}
}
}

Exceptions are real code too - especially ones that are being dealt
with.

It's just slightly more aspect oriented in style.

In fact, the whole point of AOP is to remove what they call cross
cutting concerns (like logging, persistence, thread safety, etc)
from the main code to keep it clean, without making the important
support code invisible. They do this by adding what they call
aspects from a third person perspective, into the control flow of
the normal code, by specifying where the aspect gets control in a
declarative style.

That's all it is.

It hasn't.. We still have 'or die' for raising exceptions, and you
can use, like you mentioned

It's not my suggestion, btw ;-)

Well, there is a conflict here:

you want to mark and not mark your errors at the same time.

This is feasable... I don't see why it shouldn't be implemented, but
frankly I don't see myself using it either.

This is because the types of exceptions I would want to resume are
ones that have a distinct cause that can be mined from the exception
object, and which my code can unambiguously fix without breaking the
encapsulation of the code that raised the exception.

Take OSX for example - it's very consistent in that you are allowed
to try to perform every action you like. Whenever there's a
permission denied error, it pops up a password dialog.

I think that a nice user oriented environment can benefit from a
library of generic exception softners that interact with the user:

change the mode of ureadable/writable files

enter a password for elevated priviliges

decide whether to keep trying when something seems to be timing
out

etc etc.

These are all very specific and reusable, regardless of what we're
resuming. This is nice because especially if we're trying to e.g.

my @handles = map { open $_ } @file_names;

we can let the user skip unreadable files, by using return with no
value instead of returning a handle. This is a generic pattern that
enhances the user experience by not forcing the user to start over
again.

For more specific code, i doubt there will be several exceptions of
the same kind in a call chain.

The catch block's caller is greet's caller.

I guess you want

$!.position.label.yadda

or something like that

For cleanup we have real useful garbage collection, with a
declarative interface to decide on how an object needs to disappear.

Resource management is the task of the resource creator, not
exception handler, IMHO. It's just too hard to get it right.

So your point:

is very valid

Continuations give this behavior consistently.

They just need to be garbage collected themselves, in a way.

What I would like to disallow is the ability to take $! and just
.resume it out of the blue in code that isn't an exception handler.
That just does't make sense:

try { ... }
some_other_stuff;
$!.resume if $!;

Again, that is exactly what a continuation is, and parrot already
has them =)