This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

UTF-8 fallback and no warning

Posted by Fiendish on Wed 02 Apr 2014 03:39 AM — 10 posts, 33,687 views.

Fiendish USA Global Moderator #0
Quote:
Previous line had a bad UTF-8 sequence at column 21, and was not evaluated for trigger matches

seems like harmful behavior. Would it not be better to (maybe optionally) fall back to a non-UTF-8 interpretation for the bad sequence instead?
Nick Gammon Australia Forum Administrator #1
The triggers are pre-compiled for speed, and they were compiled expecting UTF-8.

Besides, don't you want to know if things aren't working as expected?
Fiendish USA Global Moderator #2
Quote:
Besides, don't you want to know if things aren't working as expected?

That's a really interesting question that I never have a perfect answer for.
Now that I think about it, though, I'm kicking myself for never thinking to try to figure out a way to do an automatic bug report from Aardwolf package users without player effort.

Can we get a plugin callback that fires on script engine errors and gets passed the stack trace?
Amended on Sat 05 Apr 2014 09:09 PM by Fiendish
Nick Gammon Australia Forum Administrator #3
Naturally I wonder what would happen if the script which handles script errors fails.

Possibly we could have a "error reporting" plugin whose job it is to do what you suggest, and which itself would not be called in the event of a script error.

I wonder what the best way of storing this stuff would be? Maybe a SQLite3 database which records stuff like:

* plugin name (if any)
* date/time
* what the error was
* what was called
* backtrace

More-or-less what appears in the main window, plus a timestamp in fact. Or maybe just a text file which is opened "append" and dump the stuff from the output window to it.

I'm not sure what you would do if some script error caused thousands of entries to be written to the database.

Something like this maybe (in the error.log file):


< date / time >

Run-time error
Plugin: Source_scanner (called from world: smaug2)
Immediate execution
[string "Plugin"]:41: The specified module could not be found.

stack traceback:
        [C]: in function 'assert'
        [string "Plugin"]:41: in main chunk
Error context in script:
  37 : 
  38 : -- for opening editor and bringing it to the front
  39 : -- available here: http://www.gammon.com.au/files/mushclient/lua5.1_extras/windows_utils.zip
  40 : 
  41*: assert (package.loadlib ("windows_utils.dll", "luaopen_windows_utils")) ()
  42 : 
  43 : require "alphanum"
  44 : os.setlocale ("", "time")
  45 : 
[WARNING] C:\Program Files\MUSHclient\worlds\plugins\Source_scanner.xml
[WARNING] C:\Program Files\MUSHclient\worlds\smaug 2.MCL
Nick Gammon Australia Forum Administrator #4
Maybe if this is done automatically we don't actually need a plugin.
Fiendish USA Global Moderator #5
Nick Gammon said:
Naturally I wonder what would happen if the script which handles script errors fails.


That shouldn't be a problem, because plugins that fail stop running until reloaded.
Nick Gammon Australia Forum Administrator #6
If there was an error, would you like to see:

  1. The error on the output window and copied to a error log file.
  2. It to silently fail (ie. no message in the output window), but be copied to the error log file.
  3. A brief warning (eg. one line in red) and the full error copied to the error log file.
Amended on Mon 07 Apr 2014 11:08 PM by Nick Gammon
Fiendish USA Global Moderator #7
I think visible erroring is useful. Especially since errors stop function until reload. So 1 would be my preference of those three.
Nick Gammon Australia Forum Administrator #8
See:

https://github.com/nickgammon/mushclient/commit/3abbb94

Also a description in the release notes:

http://www.gammon.com.au/scripts/showrelnote.php?version=4.92&productid=0
Nick Gammon Australia Forum Administrator #9
Fiendish said:

Quote:
Previous line had a bad UTF-8 sequence at column 21, and was not evaluated for trigger matches

seems like harmful behavior. Would it not be better to (maybe optionally) fall back to a non-UTF-8 interpretation for the bad sequence instead?


In version 4.93, bad UTF-8 sequences are now translated, as best as they can be, into the equivalent character from the current code page. This message should therefore not appear again.