eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[parser] Remove locInfo from Error Messages #492

Open eclipse-ocl-bot opened 2 hours ago

eclipse-ocl-bot commented 2 hours ago

| --- | --- | | Bugzilla Link | 298629 | | Status | NEW | | Importance | P3 minor | | Reported | Dec 30, 2009 02:34 EDT | | Modified | Nov 08, 2011 04:49 EDT | | Blocks | 318368 | | Reporter | Ed Willink |

Description

Many ProblemHandler.ERROR_MESSAGES such as

OCLParseErrorCodes_SUBSTITUTION_SECONDARY = {0} {1} expected instead of {2}

have a {0} binding for location information. It is unclear whether this was ever useful to users. Since it was clutter for many in AbstractBasicEnvironment.parserError we find the clunky

String messageTemplate = ProblemHandler.ERROR_MESSAGES[errorCode].substring(4);

but do not find the same in lexerError.

The position is available for those whose custom ProblemHandler uses all the parameters of handleProblem.

The presence of the locInfo makes it difficult to write accurate message content tests, without emperical counting of the expected indexes, or an independent substring(4).

Suggest: we eliminate the {0} locInfo binding from all messages so that tests can use the message template as is.

eclipse-ocl-bot commented 2 hours ago

By Alexander Igdalov on Dec 30, 2009 05:58

(In reply to comment #0)

Many ProblemHandler.ERROR_MESSAGES such as

OCLParseErrorCodes_SUBSTITUTION_SECONDARY = {0} {1} expected instead of {2}

have a {0} binding for location information. It is unclear whether this was ever useful to users. Since it was clutter for many in AbstractBasicEnvironment.parserError we find the clunky

String messageTemplate = ProblemHandler.ERROR_MESSAGES[errorCode].substring(4);

but do not find the same in lexerError.

The position is available for those whose custom ProblemHandler uses all the parameters of handleProblem.

The presence of the locInfo makes it difficult to write accurate message content tests, without emperical counting of the expected indexes, or an independent substring(4).

Suggest: we eliminate the {0} locInfo binding from all messages so that tests can use the message template as is.

+1. Moreover, substring(4) of an internalized string is a potential source of localization errors and causes extra (undescribed) constraints for translators.

eclipse-ocl-bot commented 2 hours ago

By Alexander Igdalov on Dec 30, 2009 05:59

internalized -> internationalized