The erroring proc's arguments and the name and value of the erroring variable would also be helpful.
In response to MisterPerson
MisterPerson wrote:
The erroring proc's arguments and the name and value of the erroring variable would also be helpful.

I suppose the arguments could potentially be helpful, but IMO that's overkill. But there's no such concept as an "erroring variable" because there are several different kinds of errors that have no thing to do with vars. Anyway the most common runtime errors are extremely clear already.
I'm going ahead and adding an error handler, world.Error(), that if defined will deal with the error message assuming try/catch are not in play. Effectively it'll act like a global try/catch.
In response to Lummox JR
What about errors that happen on the client-side only though such as when a user types in the name of a verb that doesn't exist?

Is there a way to catch these error messages to display them when there's no output control present?
In response to Superbike32
Isn't that what client.Command() is for, kind of?
In response to Superbike32
Superbike32 wrote:
What about errors that happen on the client-side only though such as when a user types in the name of a verb that doesn't exist?

Is there a way to catch these error messages to display them when there's no output control present?

No. Those errors never make it to the server; they're not runtime errors in the same sense.
I've pretty much finalized this.

- The try/catch keywords are used for places where you know there's a risk of an error and want to handle it specially.

- The throw keyword lets you throw an exception; it can be any value.

- When try/catch isn't available to catch an error, world.Error() will do so; the current proc will crash as expected, and return to the caller. You can override world.Error() to change where the output is sent. Yes, you can call ..() to still output to world.log.

- The /exception datum contains name, file, and line info, along with desc (the stack trace). The desc value is added if and only if this is a regular runtime error and world.Error() handles it; it's pointless overhead otherwise. (The desc info will behave just like current info, where after a number of runtime errors it'll get less verbose and finally stop filling in altogether.)

- There's an EXCEPTION(message) macro that creates an /exception datum and fills in file and line info. It's equivalent to new/exception(message,__FILE__,__LINE__).
ily lummy
Wicked. The ability to try/catch and use custom exceptions will really, really clean up some of my code
Lummox JR resolved issue with message:
Error handling has been added. You can use the new keywords try and catch to setup error handling within a proc (it will also apply to procs called inside the try/catch). The new throw keyword can throw an error. And a new proc world.Error() can be overridden to handle errors at a global level--i.e., when no try/catch is available to handle them. See the DM reference for more details.
Page: 1 2 3