View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000206||LDMud||Runtime||public||2004-11-26 22:52||2009-10-02 10:06|
|Summary||0000206: Error handling inside a hook|
|Description||Short: Error handling within a catch.|
From: Michael Sporn
Immediate error handling should be independent from a catch(), as too
many people forget to handle errors returned by a catch.
Maybe a modification to runtime/heartbeat/log_error, giving an extra
parameter 'is_caught', and if is_caught is true, the return value decides
if the driver prints a traceback or not before doing the actual catch.
In general, the error and diagnostic handling is much too confused.
--- See the discussion on amylaar-users in November '2000. The error routine
could be set by a hook, and if not set, the driver could fall back to the
|Tags||No tags attached.|
|External Data (URL)|
||I agree, that catch() was often (and is still sometimes) bad, because the error does not get visible except for the people reading the debug log (not many). The ;publish modifier changes that to a degree. But maybe a possibility to implicitly use ;publish by default, enabled by some compiletime, commandline option or pragma...?|
||If you do not want to introduce an new pragma - I consider 'pedantic' to be quite suitable for such a behaviour.|
||What about the other catch modifiers. Should a mudlib or program be able to change their default, too? (We have a default statement, might use that?)|
Default statement? Uh, never read about that. :-(
If we enable to change the default behaviour, we may also introduce log and nopublish in addition to nolog and publish to override default behaviour, I guess.
BTW: related is the wish to disallow to use certain modifiers, e.g. disallow nolog. I think, there was/is somewhere an issue dealing with that.
|2009-09-26 19:56||zesstra||Note Added: 0001307|
|2009-09-27 14:53||Sorcerer||Note Added: 0001314|
|2009-09-29 13:06||Gnomi||Note Added: 0001338|
|2009-09-30 16:11||zesstra||Note Added: 0001360|
|2009-10-02 10:06||zesstra||Relationship added||related to 0000352|