RFC: onError implemented with events like model

[LiQuidProQuo]

onError is documented as following

assume that each Component has it's own onError hook.

<Parent>
   <Child>
      <SubChild/>
   </Child>
</Parent>

if an error is triggered in <SubChild/>, it will be handled by its own hook
if it want to ignore the error, and propagate it up, it is suggested by the docs that we need to rethrow
but in the case of this basic example, throwing in the onError callback, will result in unhandled exception
and the <Child/> component will have no opportunity to handle the exception.

additionally, onError is additive hook, which mean that a component can have multiple handlers at the same error scope.
when an error is detected both or all callbacks at that level will be invoked ( in the order they registered )
with the exception if the handler throws, and breaks the exection.

function Child(){
    onError(()=>handle one)   <-- if I throw 2nd handler is not called 
    onError(()=>handle two)
}

so we have 2 issues

1. errors can not bubble up to higher error scopes ( a parent component )
2. "sibling" onError breaks with unhandled exception if one of the handlers throws.

it is therefore proposed, to we provide an more control over error propagation

1. bubbleError() a util that will propagate an error up the scope.

onError((error)=>
     if( i_care_about_this_error(error)) {
       // handle it 
     } else {
      // I don't know what this error is, I don't expect, it 
      // but maybe my parent wants to know about it or handle it  so here you go
     // not my problem
      bubbleError(error)
    }
}

2. perhaps in my component, I want to be able to say, I took care of this problem, so don't worry about it for other handlers at the same level

onError((error , {stopImmidiatePropogation,bubbleError})=>{
    if(  isErrorNotMyConcern(error ){
         // ok, my other handlers should not care about this
         stopImmidiatePropogation()
        // but my parent should know about this 
         bubbleError(error)
    }
})

3. throwing in onError handler, could potentially be handled internally as
   stopImmidiatePropogation and bubbleError to the parent scope

if handlers on same level wants to communicate, they can mutate the Error Object
but it is important to note, that each handler is technically a standalone, and should be invoked independently
unless user intervened in the natural execution flow

[ryansolid]

Yeah this is an argument for why onError probably is a poor API design. Error Boundaries and Boundaries in general are really designed as UI concern. I wouldn't mind seeing what other reactive libraries have done but I think this probably should be a view thing.

Ideally there would only be a single one at a level. From that perspective problem 1 is a shortcoming. You should be able to throw from onError and have it go up to a parent.

Funny enough ErrorBoundary Component doesn't suffer from this as if the error happens on Component education it will go up to the next ErrorBoundary. I debated even exposing onError. Because really it is a bit like Suspense.. But I do feel it is more adaptable. Other components should be able to act as Error Boundaries perhaps. The replace all children behavior doesn't have to be the behavior. But the current solution doesn't account for multiple at the same level nor could it.

I wonder if it should be more like a component builder that passes error as a signal through the props.

const ErrorBoundary = createErrorBoundary((props) => {
    return <Show when={props.error} fallback={props.fallback}>
      {props.children}
    </Show>
})

Etc.. I'm sure reactivity purists like onError exists but I sort of feel like a lot of the reason for it existing is to bound off effects.. I guess that is the other option. Give it a root like API.

createErrorRoot(() => {
  // only catches things created in here.
}, (err) => // handles error)

Both of these are better for the intent I think. Try Catches don't have sibling catches.

[LiQuidProQuo]

throw is pretty much interchangeable with what the bubbleError
I use bubbleError to show the intention explicitly, mostly because I did not see throw working as documented.
also bubbleError has the potential to explicitly bypass your component boundary if implemented as a primitive

I am not suggesting that error automatically propagate, though there are use cases for that.

I mostly suggest we gain better power to control the flow of error, similar to powers we have in dom events.
there is no suggestion by me that we auto propagate up, only that we can do it manually by throw/bubbleError
and that we can stop propagation to sibling.

though having an error channel is not a bad idea ( event bus for errors )
but I have not considered the implications or use cases so I will leave this out of the conversation for now.

• stop immediate propagation stopImmidiatePropogation
• stop immediate and propagate up ( stopImmidiatePropogation + throw / bubbleError)
• do nothing - only same level handlers are called.

[ryansolid]

My thinking with the current design was that it was like onCleanup like we'd just gather them all together and pretend like they are a single one. With that I don't see the argument for reversing the order. That just changes the execution between when it first renders and when it updates. If more handlers are added at the same level afterwards. I'd expect them to be additive. That being said I kinda feel like all error handlers at a level should be hit if you registered them, like they shouldn't really be aware of each other. This poses a problem if one throws before the others finish. I suppose the source is to try catch each handler and collect and errors and run the parent level up. Just seems a bit heavy. Not sure.

[lxsmnsyc]

@ryansolid Ah you meant if one of the child errors throw, then the siblings shouldn't be evaluated, which makes sense, but that's if we are talking about consecutive onError calls

[ryansolid]

Yeah.. more and more I am thinking this was just a poor design. The more I think about this siblings shouldn't exist. I see convenience in being able to add little error handlers here and there but error handling are scoped blocks by nature. I suspect this is a Solid 2.0 consideration. I'm very much leaning towards a scoped error boundary of sorts that works without components.

catchError(() => {
  // only catches things created in here.
}, err => {
  // handle error
})

And then this is just a reactive context, component independent scoping mechanism

[LiQuidProQuo]

catchError is already implementable with onError + createComputed

https://playground.solidjs.com/anonymous/3de6acf5-dff7-4b46-b71d-1cd41321036a

both of which are planned to be removed/deprecated from solid.