For the cases you want to throw (e.g. vector of integers with floating point b), I would add a check that throws with a helpful error message, or define a method that this case hits to throw a helpful error message.
If the types are known at compile time (i.e. the call to foo is typestable), this would have 0 runtime overhead in the cases you support.
If you’d prefer a MethodError, and you’re also handling all the cases you do support with the same implementation, then you can make that implementation an unconstrained _foo, and have a foo for each case that you do support forward there.
I’d do what is simplest (so long as they have 0 runtime overhead, which is the case for all proposals here), which depends on what foo’s implementation looks like.
Like if you need different implementations on input types, it’d make sense to just define those directly, and not define the type combinations you don’t support.