Decide whether split(..., None) should return (None, None)

[njsmith]

That's what it does right now. Is there any good reason for this?

MultiError.filter passed through None, but MultiError.filter had a more general system where handlers took exceptions as arguments, and returned new exceptions as return values, and could return None to mean "this exception has been successfully handled, no exception replaces it", and that's gone in the new design.

[WindSoilder]

Here is my understanding of handler in the new picture:

caught, rest = split(.., .., ..)
handle(caught)

If handler can't handle any exceptions in caught, it will re-raise an exception (whatever user like to raise). Or we can make sure that handler handle exception successfully.....

---

Assume that my thought is right :) I think there are two ways to handle in the split(..., None):

1. just return None instead of (None, None)
2. raise an ValueError to indicate that user can only pass Exception object into split.

I would suggest the 2nd approach... The 1st approach seems fine at glance, but we will have an error when we are coding like this:

caught, rest = split(.., None, ..)

If we pick this approach, we have to use split more carefully :(
But I don't know if there are any use cases that user want to pass None into split..

[njsmith]

Yeah, I can't think of any cases where we would want to pass None into split. For catch, I guess it does something like:

@contextmanager
def simplified_catch(exc_type, handler):
    try:
        yield
    except BaseException as exc:
        caught, rest = split(exc_type, exc)
        ...

So it should never encounter a situation where exc is None. caught or rest might be None, but exc is never None.

[WindSoilder]

What about introducing type annotation here?

def split(exc_type: Type[BaseException], exc: BaseException, *, match: Optional[Callable] = None) -> Tuple[BaseException, BaseException]:

From the defininition, we don't need to check if the exc is instance of Exception.

[njsmith]

Fixed in #10