Exception handling about gjallarhorn HOT 8 CLOSED

@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)

from gjallarhorn.

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

from gjallarhorn.

@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

from gjallarhorn.

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).

from gjallarhorn.

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.

from gjallarhorn.

@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.

from gjallarhorn.

@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.

from gjallarhorn.

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.

from gjallarhorn.