Though it kind of bothered me at first, now I really like the way python handles the semipredicate problem

P6's design for run-time warnings, errors and delayed exception handling is anchored on Failure objects:

... dynamic context can determine the treatment of failures that in other languages would always throw exceptions. This gives Perl 6 programs the flexibility to handle exceptions either in-band or out-of-band. It is particularly important to be able to handle exceptions in-band when you are trying to perform parallel operations, so that the failure of one computation does not result in fratricide of all its fellow computations. (You can think of this as analogous to the way NaN propagates through floating-point calculations.)

(from the design doc / section S02 / Undefined types)

A simple use of this flexibility is the 'fatal' pragma that controls whether "built-ins ... automatically throw exceptions on failure" in its dynamic scope:

use fatal;
[download]

The fail function responds to the caller's use fatal state. It either returns an unthrown exception, or throws the exception. Before you get too happy about this pragma, note that Perl 6 contains various parallel processing primitives that will tend to get blown up prematurely by thrown exceptions. Unthrown exceptions are meant to provide a failsoft mechanism in which failures can be treated as data and dealt with one by one, without aborting execution of what may be perfectly valid parallel computations. If you don't deal with the failures as data, then sink context will automatically throw any unhandled Failure that you try to discard.

In any case, the overriding design principle here is that no unhandled exception is ever dropped on the floor, but propagated outward until it is handled. If no explicit handler handles it, the implicit outermost exception handler will eventually decide to abort and print all unhandled exceptions passed in as its current @! list.

It is possible to fail with a resumable exception, such as a warning. If the failure throws its exception and the exception resumes, the thrower by default returns the null string ('') to whatever caused the failure to throw its exception. This may be overridden by attaching a .resume_value to the warning. Hence numeric coercions such as +"42foo" can be forced to return 42 after issuing a warning.

(from the design doc / section S04 / Exceptions)