View Issue Details

IDProjectCategoryView StatusLast Update
0000763LDMud 3.5Runtimepublic2018-01-30 03:59
Reporterzesstra Assigned ToGnomi  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Platformx86_64OSMacOS XOS Version10.5.x
Fixed in Version3.5.0 
Summary0000763: Introduce pragma to downgrade RTTC errors to warnings
DescriptionXtian on ldmud-talk expressed the wish to convert the errors raised during RTT checks into warnings to ease the conversion/transition process.
While I don't like to downgrade the errors to warnings in general, an additional pragma would be OK.
Additional Informationhttp://mail63.csoft.net/pipermail/ldmud-talk/2010-November/000212.html
http://mail63.csoft.net/pipermail/ldmud-talk/2010-November/000214.html

Hello World,

On 11.11.10 11:51, xtian wrote:
> > When you enable run time type checks (these are rather new in the 3.5
> > branch) the driver throws fully-fledged errors when it encounters an
> > invalid type.
There are three reasons this being errors instead of warnings:
If you use type checks (strong_/strict_types, the compile-time equivalent of
rtt_checks), the compiler will regard incompatible types as errors. My opinion
is, that it should also be an error at runtime for consistency reasons - it is
still a programming error. (I know LPC was basically type-less - that is not
the point here because the programmer explicitly requested typechecks.)
Second reason is that if a programmer requests a specific type and enables the
RTTC, she relies on receiving only compatible types and usually does not
bother with own typechecks. If that assumption is not true, the programmers
code will probably fail at some point. Therefore I have to keep my own checks
if there are only warning upon incompatible types.
Third reason is my experience, that very few people take warnings serious and
the vast majority just ignores them.
That being the rationale for throwing errors - but please stay with me until
the end of this mail.

> > Now we (avalon) tried that out on a few corelib files and always hat to
> > revert rather quickly because - well we were flooded with errors and
> > players just couldn't continue playing normally. So for us, at the moment,
> > throwing errors does hinder adaption of this new feature. And I was rather
> > looking forward to using the checks generously.
We had similar experience when enabling strong_types+save_types in the corelib
- it took me several months of testing and fixing in my homemud until I could
enable them for good in MorgenGrauen. In case of the RTTC I enabled them in my
homemud and used a kind lib tester (It loads every known object, clones them
if suitable and moves some testplayers into every room, looking at all the
details in them... Not bulletproof, but very handy nonetheless). After that we
could enable them for real - there were errors, but not too many to handle them.

> > Enabling RTTC in an testing environment will never catch all the problems,
> > so players will always stumble over such an error - and for them something
> > will thus not work.
Yes. There is nothing better for testing than real players.
I think, it is acceptable for players to encounter the one or other bug, if
they are dealt with quickly and it does not happen too often. We therefore
accept a certain amount of false-negatives. (I accept that you might have
other demands in your mud, just wanted to add my point of view.)

> > In short, throwing errors (for a language change or enhancement) is not
> > suitable for a productive environment.
No mud (I know of) is a pure 'productive environment'. There is always more or
less development in the live mud and there are always errors in presence of
players.

> > I would much rather have the RTTC throw warnings. (the mudlib can always
> > convert them to errors if it likes). This gives the wizards all the time
> > they need to correct code while not interrupting normal gameply.
For mainly the first two reasons given above I would definitely not like to
raise only warnings during the RTTC. But I see your wish for a smoother
transition if you are confident that warnings are sufficient in your mud.
But instead of an optional pragma which optionally upgrades warnings to errors
I suggest an optional pragma which reduces the errors to warnings.
You then may still apply domain-specific combinations of rtt_checks and
rttc_onlywarn in the autoinclude hook and remove the downgrading pragma once
you feel confident (hopefully soon ;-) ).

Side note: I feel not too good about using sloppy/pedantic for this purpose,
because it enables errors I might not really want to have if I only want to
have consistent type checks and rely on compatible argument/return types. Or
to put it differently: for having a usable enforcement of types I should not
have to buy a whole different class of errors as well.
The warnings pedantic changes to errors are really a lot _less_ serious than
invalid types when the programmer wants to have only compatible types.

Bye,
Zesstra@MG
TagsNo tags attached.

Activities

zesstra

2011-11-22 10:09

administrator   ~0002084

I am afraid, I won't find time for this too soon. So if anybody else wants to work on it, please feel free.
Note: It is not as simple as it looks (set a flag, call warnf instead of errorf), because the stuff manipulates the stack to get to the needed information and that can't be done in case of warnings. It therefore requires some more changes.

zesstra

2018-01-28 21:31

administrator   ~0002295

Fix committed in revision a3089ceb747b8b996cb5222549c9424369211f92 to master branch (see changeset 1144 for details). Thank you for reporting!

Gnomi

2018-01-29 18:59

manager   ~0002302

Fix committed in revision a3089ceb747b8b996cb5222549c9424369211f92 to master branch (see changeset 1208 for details). Thank you for reporting!

Gnomi

2018-01-29 19:34

manager   ~0002348

Fix committed in revision a3089ceb747b8b996cb5222549c9424369211f92 to master branch (see changeset 2410 for details). Thank you for reporting!

Gnomi

2018-01-29 21:57

manager   ~0002353

Fix committed in revision a3089ceb747b8b996cb5222549c9424369211f92 to master branch (see changeset 2531 for details). Thank you for reporting!

Gnomi

2018-01-30 03:59

manager   ~0002404

Fix committed in revision a3089ceb747b8b996cb5222549c9424369211f92 to master branch (see changeset 2412 for details). Thank you for reporting!

Issue History

Date Modified Username Field Change
2010-11-11 16:37 zesstra New Issue
2010-11-11 16:37 zesstra Status new => assigned
2010-11-11 16:37 zesstra Assigned To => zesstra
2011-11-22 10:06 zesstra Assigned To zesstra =>
2011-11-22 10:09 zesstra Note Added: 0002084
2011-11-22 10:09 zesstra Status assigned => acknowledged
2011-11-22 10:09 zesstra Target Version 3.5.0 =>
2016-11-28 19:06 Gnomi Assigned To => Gnomi
2016-11-28 19:06 Gnomi Status acknowledged => assigned
2017-09-30 16:04 Gnomi Status assigned => resolved
2017-09-30 16:04 Gnomi Resolution open => fixed
2017-09-30 16:04 Gnomi Fixed in Version => 3.5.0
2018-01-28 21:31 Source_changeset_attached => ldmud.git master a3089ceb
2018-01-28 21:31 zesstra Note Added: 0002295
2018-01-29 18:59 Gnomi Source_changeset_attached => ldmud.git master a3089ceb
2018-01-29 18:59 Gnomi Note Added: 0002302
2018-01-29 19:34 Gnomi Source_changeset_attached => ldmud.git master a3089ceb
2018-01-29 19:34 Gnomi Note Added: 0002348
2018-01-29 21:57 Gnomi Source_changeset_attached => ldmud.git master a3089ceb
2018-01-29 21:57 Gnomi Note Added: 0002353
2018-01-30 03:59 Gnomi Source_changeset_attached => ldmud.git master a3089ceb
2018-01-30 03:59 Gnomi Note Added: 0002404