It's possible to catch all the errors related only to AlpineJs directives?

[fabiofranzini]

Hi,
I post here the discussion that we had on Discord.
I need a way to be notified from AlpineJS for all errors that come from the directives.

If there are errors for example in the binding (or another directives), I'm able to see the errors log in the console but could be great to have a callback to catch this kind of errors to manage and do something like inform the user via UI.

I'm starting to build an application that permit the user to personalize at runtime the application using a code editor in page and AlpineJs as the framework.

So I need to intercepting and re-throwing errors from evaluation inside of Alpine using something like a custom event on the Alpine object.

What do you think?

[SimoTod]

you can use window.onerror

[fabiofranzini]

This is an option but not the most elegant (my opinion) because it would conflict if some other library used the same function name (it could be). The exception with a specific property indicating who threw it would be interesting.

[HugoDF]

One suggestion I made was to add a field onto the error here wherever we re-throw it: https://github.com/alpinejs/alpine/blob/master/src/index.js#L98 something like error.__x = true 😄

At the same time, I think checking the error stack for saferEval or saferEvalNoReturn is the same and can be done in userland.

[fabiofranzini]

I like to have a field into the error (this is the minimal way to awe the certainty) but I think that have a custom event at Alpine object to send the error cached by the saferEval or saferEvalNoReturn could be better (My opinion). 😀

[SimoTod]

@HugoDF That won't work, probably (hard to tell without knowing the implementation details), because it's not said that the exception that Fabio needs to catch occurs the first time.
Since he's giving the opportunity to change a directive dynamically, it could be that the object was created with a legit value and edited later on. Those exceptions will be thrown by components and they won't go through the Alpine class.
To implement what Fabio wants, we probably need to add 2 try-catches in those eval function and do something there.
This will fix Fabio's issue but it's not really needed by the rest of the community so it creates a precedent. Tomorrow another could say: "I need to build something fancy, can you ask the name of the directive in the error object and so on".

@fabiofranzini Yeah, I appreciate it's not elegant but it's doable. By the way, feel free to open a PR to implement it or work with Hugo on that PR. The final decision is on Caleb, just be ready in case it will not make into the core.

[fabiofranzini]

@SimoTod I fully agree with you, especially in avoiding opening a precedent. I try to understand how this can be managed and to look for a feasible solution that works for everyone.