Add Compound error return (Spearbit #33)

[pakim249CAL]

Pull Request

Issue(s) fixed

This pull request fixes #1535

[MathisGD]

• why don't you kept the previous errors, which were more explicit, and just added the error code ?

• btw those need to be remove if we keep the new ones

[pakim249CAL]

• why don't you kept the previous errors, which were more explicit, and just added the error code ?

  • btw those need to be remove if we keep the new ones

Actually, I think kicking back Compound's errors is more appropriate than using our own custom errors. It is already a given and obvious from a stack trace what function call has an error. I think reverting with a Compound Error provides a good understanding of the error to those that get it. @MathisGD

[MerlinEgalite]

LGTM but I agree we must remove the old errors

[Rubilmax]

It is already a given and obvious from a stack trace what function call has an error

I'm not sure an integrator not compiling the contracts would have the same level of granularity on a fork (needs to be tested, but not a priority for now). Also, all integrators don't use forge and don't have such granular stack traces...

Which is the reason I stand for granular custom errors (instead of a generic CompoundError), still carrying the underlying compound execution code

[pakim249CAL]

Sorry for the force push. I accidentally commited work intended for another branch, so I reverted.