event raised in case of errors

[coamenel]

Hi,

I'm new to these forums, so not entirely sure if this is the right place to post this thread, apologies if it isn't

I have been working on a package for Achaea for quite a while now, and have shared that with a few people during the past year. As I add functionality, the people that also use it sometimes bump into non-functioning aliases/triggers/etc. I've established that finding the culprit can be hard when I'm not the person running into them and sometimes people have a hard time finding the appropriate errors from the errors pane.

Given that, I was looking for a way to keep the latest ten errors given in a separate logfile, along with the commands entered (probably using the sysDataSendRequest event). So I was wondering if Mudlet has an event built in that is raised when something is being logged to the error pane? I don't think the error-pane and/or debug-pane are currently writing their contents to a file, but I'm not sure.

E.g.:

Code: Select all

12:24:32.998 [ERROR:] object:<PromptParsing> function:<Trigger496>
12:24:32.998          <[string "Script: RemediesConsole"]:27: bad argument #1 to 'pairs' (table expected, got nil)>

Logging the error above to a file would enable me to simply request the user to send me that file (or add a function that uploads it to somewhere). Which would make finding the cause of their issues simpler for me.


Any pointers on the matter, if any, would be very much appreciated.

[Vadi]

Use pcall when running code, you can then catch if it errored out! Here's an example: https://github.com/svof/svof/blob/3a1ca ... r.lua#L127

[Jor'Mox]

If you are trying to catch random errors via pcall though, you will have to use pcall with all your top level function calls, as opposed to the intermediate and more controlled use in Vadi's example. And, in all likelihood the specificity you get with error logging in the error pane (which gives the line on which the error occurred) will be lost via this method. On the other hand, I suppose you could use pcall on literally every function call in every script, with some sort of elaborate system in place to track what is erroring out where, but that is likely to be WAY too cumbersome to be functional.

In other words, I can see the value in what you are talking about in the OP, but no such system exists, to my knowledge. Generally, when trying to get people to pick out the errors for remote debugging, I rely on the timestamp that goes with the error message, to help them narrow down which one is important.

[coamenel]

What I've built since creating this thread, is a function that adds entries to a database (with timestamp, severity, message and origin fields). The database is purged when the initial function is run (using sysLoadEvent), so I can add some form of a report-bug alias that is able to fetch the last X records with information. The point is, as goes for using pcall(), I'll have to add that to every single function in order for it to provide me with information. Running the logger-function from an event raised by a thrown lua error would make it functional right away.

Anyway, thanks for the pointer to pcall! Even though I'll have to start using it throughout the functions, it DOES provide me with a way to catch errors. So I can always start working my way down from where I think a problem may be originating from, by adding it to those functions and sending them the new mpackage and try to reproduce. I'll work something out

[Jor'Mox]

Rather than relying on pcall, I mostly do rigorous type testing of arguments, as that is the most likely source of an actual error. And by doing so, I can create my own error messages, as well as do whatever I feel is appropriate when an error occurs (like log them somewhere, in your case).

[SlySven]

Whilst raising an event when something is logged to the error console may not be feasible (what happens if the event handler itself has an error in it?) it does not seem totally beyond things to refactor the internal C++ code that writes a log from the main console of a profile to a text/HTML log file to also provide that functionality to the "Central Debug Console". I have noted this down as Issue 1432...