Will Datatables ever extend browser Error and ErrorEvent types instead of using custom types?

Will Datatables ever extend browser Error and ErrorEvent types instead of using custom types?

adjenksadjenks Posts: 22Questions: 6Answers: 0

I tried catching DataTables events with the global event handler (window.onerror) but their callback signature is structured differently from the standard ErrorEvent objects in browsers. This made my error logging show up empty.

Do you think it a future release you might actually extend the ErrorEvent object or Error objects found in browsers?
By making a new ErrorEvent() we can expect to find the properties lineno, colno, filename, message, and even stack depending on the browser. The error events that are currently thrown do not have all of these usual properties and I have to handle datatables errors specially to get information out of them. The current event contains type, timeStamp, isTrigger, namespace, rnamespace and target which aren't too useful to me for debugging.

Here's mozillas page on error events:
https://developer.mozilla.org/en-US/docs/Web/API/ErrorEvent
Here's how they suggest to extend the Error object:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error#Custom_Error_Types
However I think for datatables we would like to extend the ErrorEvent type in a similar way:
https://developer.mozilla.org/en-US/docs/Web/API/ErrorEvent

Would anyone else like to see this?

This question has an accepted answers - jump to answer

Answers

  • allanallan Posts: 63,893Questions: 1Answers: 10,531 Site admin
    Answer ✓

    Sounds like a good idea to me - thanks for suggesting this. I've added it to my list for the next major version.

    I'll update this thread when I've looked into it a bit more.

    Regards,
    Allan

  • adjenksadjenks Posts: 22Questions: 6Answers: 0

    I'm glad you like the idea. I look forward to seeing it. If all goes well, users should be able to receive the same amount of debugging info from datatables errors, while still being able to depend on the standard Error interfaces.
    Sadly the onerror callback signature is a bit unpredictable between browsers, but picking the most common one is probably the best option. What I mean by that explained a bit better on this page:
    https://developer.mozilla.org/en/docs/Web/API/GlobalEventHandlers/onerror

    that states:

    For historical reasons, different arguments are passed to window.onerror and element.onerror handlers (as well as on error-type window.addEventListener handlers).

This discussion has been closed.