PHP RFC: Ripples

• Version: 0.1
• Date: 2013-10-30
• Author: Joe Watkins, krakjoe@php.net
• Status: Draft
• First Published at: http://wiki.php.net/rfc/ripples

In the world of programming, there are basically two ways to deal with errors, and one to have those errors affect the flow of execution.

One, is not very many. There is a problem in a world where there is only one way to do anything at all, but in particular it causes a problem for us:

$socket->connect();
 
try {
   while ($socket->connected()) {
     try {
       $data = $socket->read();
 
       try {
         while (($buffer = $transcoder->transcode($data))) {
 
         }
 
       } catch (DataDecodeException $dde) {
 
       }
     } catch (SocketReadException $sre) {
 
     }
   }
} catch (SocketDisconnectedException $sde) {
 
}

This is, horrible. It's horrible because the flow of execution is fragmented and broken. None of us design code to be fragmented or broken, but we cannot deny that “fragmented and broken” is a perfectly valid description of the code above.

Questions:

1. what is an exception ?
2. what does it signify ?

Answers:

1. an exception encapsulates or describes an error
2. an exception signifies the the flow of execution must be broken, and that the vm must jump to another fragment of code in order to continue execution.

So, that's exceptions dealt with, they create fragmented and broken flow.

Warnings have an even bigger problem in that they do not affect your code at all; you only see them during development, once deployed your code is not even aware they have been raised.

Our code can only detect such conditions deductively by extrapolating it from the current state of the program; inferring such conditions exist by executing a considerable amount of logic.

What constitutes a warning currently, does not necessarily constitute an exception; take the arbitrary example of a socket timeout, such conditions do not necessarily mean that the flow of execution is broken, the problem may well be temporary, or rectifiable in code.

So, that's warnings, they don't affect anything in any useful way and cause us to undertake more work than is necessary.

A Ripple will encapsulate or describe conditions on the scale from warning to exception, a dam will deal with those conditions and, if no exceptions/returns/exits [unsure of these conditions] occur while dealing with them, allow the vm to execute the block that dropped the Ripple again.

try {
   while ($socket->connected()) {
     try {
       $data = $socket->read();
 
       try {
         while (($buffer = $transcoder->transcode($data))) {
 
         }
 
       } catch (DataDecodeException $dde) {
          /* this is exceptional */
          /* nothing can be done to recover execution */
       }
     } dam (SocketReadRipple $sr) {
 
     }
   }
} dam (SocketDisconnectRipple $sd) {
 
}

Dropping ripples may look like:

/* ... */
drop new SocketReadRipple($this);
/* ... */

The flow of this program could be described as fragmented, but it is not broken, execution flows from one block to another in a non-linear way.

We throw exceptions to be caught, unconditionally altering the flow of execution; we can drop ripples to be dammed, allowing execution to recover.

I have no idea ...

I think 6 ?

N/A

N/A

N/A

N/A

All

All

Do we have in ripples a viable replacement for warnings and notices ?

• You are crazy
• Write it and we will come
• I love warnings and notices and don't see the problem

Oh no, not yet. Let us discuss the idea first.