Decide whether to keep conditions

[brson]

It's not clear that we want to commit to conditions - they haven't proved effective yet and we may be 'biting off more than we can chew' by embedding them in the std APIs.

Nominating.

[thestinger]

I think in cases where functions are called to perform a side-effect like creating a directory, we could have an RAII-based Expected<T> type throwing a failure in the destructor if the error was not handled (if we truly support failing inside destructors). To handle or ignore the error, the caller would call a method to convert it into a bool or the T type - disabling the destructor. This would depend on temporaries being destroyed immediately (or at the end of the expression) rather than at the end of a block.

http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C

I find the use of conditions makes handling the error too painful, and doesn't make sense when the function can't actually recover internally. It might make sense to just represent recovery with an Option<&fn()> parameter in some cases rather than conditions.

From what I can see, conditions would be very useful for improving error handling in an existing large application, but not so much in the tiny call stacks of the standard library.

[alexcrichton]

One thing that I've found is that this suffers from one of the things I don't like about exceptions in that it's easy to have an array of conditions and forget which ones need to get handlers registered and then which ones to raise on. The runtime's I/O currently has a read_error and an io_error condition, and at least from the names it's not entirely clear what the distinction is. They're also inconsistently raised on I believe throughout the implementations because there's no guarantee that it's raised on when it needs to be.

On top of that, I've always found the syntax a little odd for something that one would expect to be dealing with frequently. Declaring the "exception handler" before the "exceptionable block" always seemed a little odd to me syntactically.

That being said, I do think that they still have good uses in a few cases, but I agree with @thestinger that for the standard library with very small call stacks back to the original invoker, I would rather see some sort of return value propagated upwards instead of a condition being raised on. I'm personally ok with Result, but I know many others have had opposition to it. I'd be interested to explore the idea of failing if you didn't handle the error, it may end up causing code to be too noisy, but it could also help expose some very real bugs.

[catamorphism]

I like that conditions can be used to implement fail-safe behavior without lots of explicit result-checking and unwrapping. I don't like the fact that "replace the erroneous value with a new one, then return control to the callee" is a high priority when in my own work, I've never run into a scenario when that actually happens. It just seems to make things awkward. Maybe I'm doin' it wrong, but if so, that's a documentation issue.

One alternative is to implement a special case of monadic "do" notation (of course we wouldn't use do) for the Result and Option monads. I think in the common case, that would be a lot less painful than the status quo.

[nikomatsakis]

I've personally found results quite nice for propagating errors backwards. I am not opposed to conditions but I confess I do not fully see how they work either.

Do notation can be implemented with a macro easily enough. However, I've personally found that the if_ok! macro used in the infer code (and a few other places) is perfect:

macro_rules! if_ok(
    ($inp: expr) => (
        match $inp {
            Ok(v) => { v }
            Err(e) => { return Err(e); }
        }
    )
)

Basically this takes a Result<T,E> expression and propagates the error, hence the resulting type is just T. This can then be used like so:

        let tps = if_ok!(self.tps(as_.tps, bs.tps));
        let self_ty = if_ok!(self.self_tys(as_.self_ty, bs.self_ty));
        let regions = if_ok!(relate_region_params(self,
                                                  item_def_id,
                                                  &as_.regions,
                                                  &bs.regions));
        Ok(substs { regions: regions,
                    self_ty: self_ty,
                    tps: tps.clone() })

I would not object to some sort of macro for dealing with results being part of the standard library.

[brson]

Let's remove conditions.

[catamorphism]

I'm ok with that, but I think we should add the macros that Niko suggested to the standard library before removing conditions.

[catamorphism]

1.0, back-compat

[Florob]

FWIW, I actually like conditions a lot for cases where you can handle the error and continue. I currently use them in my XML library when an entity is not recognized. It allows users to catch e.g. © not being defined and passing back a ©. I wouldn't know how to do this nicely without conditions.

[huonw]

@Florob, except for the condition! macro, conditions are actually defined entirely in std::condition, so you should be able to adapt the functionality you need.

[Florob]

@huonw, Yes I will certainly survive if this feature is removed.
My point is, there are cases where conditions are generally useful, and others (like opening files) where they are not. Just like the Condition and Error-handling Tutorial actually suggests.

I would agree that conditions are currently not properly utilized in the stdlib though. From a first look a somewhat sensible case could be the str::not_utf8 condition, but it would be far more useful if the handler got the index of the first bad byte as an integer value, and not embedded in some error string. It would also be possible to allow replacing a sequence of bad bytes, instead of having to return a replacement for the whole string. The beauty of conditions, to me, really is that you can call into the handler more than once.

[thestinger]

I would prefer using an explicit handler function parameter when the condition paradigm is needed. The TLS implementation allows adding conditions without changing the external API, but I consider that to be a bad thing...