You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the solution you'd like
Anytime I schedule an IInvocable, I need to ensure that I've registered it to the IoC. Remembering to add it is not such a big deal (though I'd like not to have it), however if any of the class' dependencies is not present, than the AddTransient<MyInvocable> won't fail and the app will run with the IInvocable never been invoked at all.
Describe alternatives you've considered
Ideally, I'd like to have the library take care of instantiating the IInvocable objects whereas the necessary dependencies are fetched from the IoC container. Thus:
The library will fail, if the configuration is not proper, instead of failing silently.
We don't have to remember to register the IInvocable (IMO, logically the IInvocable doesn't really fit being in the container and having anyone else .Get it)
We can have a feature toggle whether to fail silently or not, whether to fail fast or not. We can have the default for this feature toggle be disabled for the time being and backwards compatibility, and for the next major release to have the default be enabled and fail-fast.
Let me know what you guys think about this feature proposal. I will be happy to dig into the code, should the maintainers are happy with the suggested behavioural change.
The text was updated successfully, but these errors were encountered:
Should exceptions be thrown by default? Perhaps if the IInvocable type isn't found. This would have to be verified that it works with Coravel Pro too (which is not open), so would take a bit of work / coordination.
For the time being, the global exception handling extension should help.
Thanks @jamesmh! The global exception handling solves the problem I had.
As for the question, personally I'd prefer if frameworks notify if they cannot perform an operation as excepted. At the same time I'm guessing there is code out there that expects the current fail silent behavior.
Maybe a new flag to to the method that defaults to current behavior, but allows the user to enable exceptions in case operation cannot be performed?
Describe the solution you'd like
Anytime I schedule an
IInvocable
, I need to ensure that I've registered it to the IoC. Remembering to add it is not such a big deal (though I'd like not to have it), however if any of the class' dependencies is not present, than theAddTransient<MyInvocable>
won't fail and the app will run with theIInvocable
never been invoked at all.Describe alternatives you've considered
Ideally, I'd like to have the library take care of instantiating the
IInvocable
objects whereas the necessary dependencies are fetched from the IoC container. Thus:IInvocable
(IMO, logically theIInvocable
doesn't really fit being in the container and having anyone else.Get
it)We can have a feature toggle whether to fail silently or not, whether to fail fast or not. We can have the
default
for this feature toggle bedisabled
for the time being and backwards compatibility, and for the next major release to have thedefault
beenabled
andfail-fast
.Let me know what you guys think about this feature proposal. I will be happy to dig into the code, should the maintainers are happy with the suggested behavioural change.
The text was updated successfully, but these errors were encountered: