|The stupid question is the question not asked|
My bias lies towards the "all errors are exceptions" end of the spectrum :-) For me it helps more than it hinders, but I understand the distinction that you're making between "normal" and "exceptional" results.
The nasty bugs caused by read all fall under the general heading of "files that should have been read totally being truncated". One instance was especially amusing since they "just knew" that the problem was with a bit of networking code that was moving the result of the read over the wire. They'd spent a week trying to track down an intermittant networking error, rather than the obvious (in hindsight) intermittant read problem.
In general I like your idea - think it would make an interesting alternative to Fatal.
However, the problem of dealing with subroutines that return false values "normally" means that it's not as useful in these cases since you have to make an explicit check for the error condition.
For me, the inconvenience of the perl5 exception "syntax" is worth the other advantages it gives me.
In reply to Re^4: Best Practices for Exception Handling (no isa)