Exception handling

[ReedCopsey]

What would be the preferred method for managing exceptions?

One option would be to go the route of observables, and have Subscription methods accept an error handling function. This would also make it easy to make functions that split a signal into two in the case of an exception - with an IObservable being passed out in the case of an exception for easy handling.

[jeroldhaas]

My immediate thought was the same, I think. CustomExceptions implementing IObservable, or simply IObservable<IException>, or something else?

[ReedCopsey]

@jeroldhaas I'm thinking something like:

let exceptions = Signal.catch someSignal

This would result in exceptions being IObservable<Exception>, which could then be subscribed/filtered/etc using the Observable module or Rx functionality as needed

[ReedCopsey]

But this would require a general mechanism for propagating exceptions through (similar to IObserver's mechanism), as well as the ability to subscribe to them somewhere - perhaps via Signal.Subscription.subscribe as well as via a custom mapper (like the above).

[jeroldhaas]

My reasoning for IException as the contained type for IObservable was for extendability by passing various forms of Exception types that other frameworks would likely try passing on to F#.

Can subscribers operate in a serial pipeline? To clarify, Signal.Subscription.subscribe previous to ErrorSignal.Subscription.subscribe in a pipeline, or would be too much? I don't see any reason why software can't have more than one Subscriber.

[ReedCopsey]

@jeroldhaas The problem with IException is that it won't work against standard exceptions, so a "global" exception handler wouldn't just push into it. That's why I was suggesting IObservable<Exception> - any framework exception could map through to that.

There is nothing stopping multiple subscriptions on a "pipeline". I was actually thinking more along the lines of having Signal.catch or Signal.handle type of functionality which would act as a "handler", and still allow normal values to flow through the system.

[jeroldhaas]

@ReedCopsey I'd looked up the MSDN docs on IException (as I'd thought there was a possibility that it already existed); my idea was to create an interface that would contain the Exception as one of its fields.

After thinking on your solution, I'm guessing that a guard that checks to see if a special Exception type is derived from the Exception type, that should suffice.

[ReedCopsey]

@jeroldhaas In most languages on the CLR, all exceptions derive from System.Exception. It's really odd to ever encounter one that doesn't (it's possible with C++/CLI to throw other things, but the docs recommend always deriving from System.Exception, and if you don't, you'll mess up almost everybody)

[ReedCopsey]

Closing this for now - given the nature of signals (always having a value, etc), this doesn't seem to be a major issue in practice, at least not yet. Going to leave the design alone unless something comes up where this becomes a necessity.