Re-direct error output to a proc

ID:1833370
 
Apr 15 2015, 5:39 am
(See the best response by Lummox JR.)
Code:
None


Problem description:

Is it possible without an output control to instead re-direct error text to a proc? I want to do this because I don't have an output control on my interface at all, I handle the ability to talk myself, and I want to extend this to errors.

The main reason for showing errors currently is when the user sets up macros in Options and Messages for things that don't exist in the game...either by calling it the wrong thing or simply mis-spelling it, and I want the user to know why, hence the error text should be re-directed and displayed the way I have it setup to.
Apr 15 2015, 12:33 pm
I have also wanted to handle the error log myself, but there is currently no easy way of doing so. This should really be a feature request.

What you can do is set the world.log var to a file which should redirect errors and some other system output to that file. Although, I do remember seeing an issue where some messages were getting cut in half, with part of it going to the default output control, and the rest going to world.log. As a workaround for what you are trying to do, I'm guessing you can read back the log file with file2text(), which could then be sent to any proc, but that's really not something you should have to do.

What would be nice is if you could send world.log to a proc before outputting it to a file. It just doesn't make sense to do the inverse. I would suggest making a feature request to be able to set world.log to a proc path, so that it sends it there as the first argument. You could also just have a built-in proc made just to handle the log. In order for any of that to actually work, the client will have to tell the server about the error or system message whenever one occurs.
Apr 16 2015, 1:17 pm (Edited on Apr 16 2015, 1:22 pm)
Best response
I believe there is a feature request for exception handling. It's one of my dream list items that I'd like to get to at some point.

[edit]
Actually, this doesn't look like it'd be horrible. If I can find a way to do it, I might try to get it into 508. I recommend looking up the feature thread anyway, because I'd welcome suggestions on what a good error handling syntax would look like.
Apr 16 2015, 1:31 pm
I'd be happy with a global Catch() that gets called anytime a runtime error is generated, perhaps with an /Error datum to read from containing the various variables about the error, like file, line, usr, src, etc etc... Obviously it would only really work in debug mode (I'd imagine)
Apr 16 2015, 2:40 pm
I think this could be tied in with a more general client.Output() proc. Something like a global Catch() proc should probably be called first, before passing the message on to client.Output(), where all forms of output must go. These procs should act like the mouse procs and only be called if used. This would of course make the current output() obsolete.

The current "control" argument wouldn't just be limited to controls. It could also have an "Options and Messages" value, or even a file name. This is assuming that logging could work for clients other than the host.

These procs wouldn't just be triggered when output occurs. They would actually intercept it, so you would need to call the default action ..() when overriding them.

I think I remember this type of thing not being feasible for sounds, but even if only text is supported, that would be fine, although it would be nice to have everything conform to a new client.Output() standard.