Concept proposal: Safely catching error

[Steven Schveighoffer via Digitalmars-d]

On 6/7/17 12:20 PM, Olivier FAURE wrote:
> On Monday, 5 June 2017 at 14:05:27 UTC, Steven Schveighoffer wrote:
>>
>> I don't think this will work. Only throwing Error makes a function
>> nothrow. A nothrow function may not properly clean up the stack while
>> unwinding. Not because the stack unwinding code skips over it, but
>> because the compiler knows nothing can throw, and so doesn't include
>> the cleanup code.
>
> If the function is @pure, then the only things it can set up will be
> stored on local or GC data, and it won't matter if they're not properly
> cleaned up, since they won't be accessible anymore.

Hm... if you locked an object that was passed in on the stack, for 
instance, there is no guarantee the object gets unlocked.

>
> I'm not 100% sure about that, though. Can a pure function do impure
> things in its scope(exit) / destructor code?

Even if it does pure things, that can cause problems.

>> Not to mention that only doing this for pure code eliminates usages
>> that sparked the original discussion, as my code communicates with a
>> database, and that wouldn't be allowed in pure code.
>
> It would work for sending to a database; but you would need to use the
> functional programming idiom of "do 99% of the work in pure functions,
> then send the data to the remaining 1% for impure tasks".

Even this still pushes the handling of the error onto the user. I want 
vibe.d to handle the error, in case I create a bug. But vibe.d can't 
possibly know what database things I'm going to do.

And really this isn't possible. 99% of the work is using the database.

> A process's structure would be:
> - Read the inputs from the socket (impure, no catching errors)
> - Parse them and transform them into database requests (pure)
> - Send the requests to the database (impure)
> - Parse / analyse / whatever the results (pure)
> - Send the results to the socket (impure)
>
> And okay, yeah, that list isn't realistic. Using functional programming
> idioms in real life programs can be a pain in the ass, and lead to
> convoluted callback-based scaffolding and weird data structures that you
> need to pass around a bunch of functions that don't really need them.
>
> The point is, you could isolate the pure data-manipulating parts of the
> program from the impure IO parts; and encapsulate the former in
> Error-catching blocks (which is convenient, since those parts are likely
> to be more convoluted and harder to foolproof than the IO parts,
> therefore likely to throw more Errors).

Aside from the point that this still doesn't solve the problem (pure 
functions do cleanup too), this means a lot of headache for people who 
just want to write code. I'd much rather just write an array type and be 
done.

-Steve