Project

General

Profile

Feature #7908

Add description about converted error traces format

Added by Vitaly Mordan about 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
High
Category:
Documentation
Target version:
-
Start date:
01/25/2017
Due date:
% Done:

0%

Estimated time:
Published in build:

Description

A short instruction of converted error trace format (for example, what symbols "[" and "{" means, which element can and cannot be used) is required, since used format is not well-known and can be changed in the future.


Related issues

Related to Klever - Feature #7915: Report that entities supplied by users have incorrect formatsNew01/26/2017

Actions
Related to Klever - Feature #7307: Support help pagesNew06/20/2016

Actions

History

#1

Updated by Evgeny Novikov about 3 years ago

Details on unknown errors can and should be found in Bridge logs. Normally the development environment resides them in bridge/media/*.log. There isn't a better place. Also there is no chance to print something good and short in any case.

#2

Updated by Vitaly Mordan about 3 years ago

Evgeny Novikov wrote:

Details on unknown errors can and should be found in Bridge logs. Normally the development environment resides them in bridge/media/*.log. There isn't a better place. Also there is no chance to print something good and short in any case.

Then it is very bad design, if "Unknown error" is the best option. Also the user should check server logs for that. It is a pity, that good ideas implemented so poorly.

At least, it is very easy to add some short instruction.

#3

Updated by Evgeny Novikov about 3 years ago

Vitaly Mordan wrote:

Evgeny Novikov wrote:

Details on unknown errors can and should be found in Bridge logs. Normally the development environment resides them in bridge/media/*.log. There isn't a better place. Also there is no chance to print something good and short in any case.

Then it is very bad design, if "Unknown error" is the best option. Also the user should check server logs for that. It is a pity, that good ideas implemented so poorly.

This is actually a very good design since it allows to find and to report the root problem.

What I can recommend - is to add "(please inspect logs for details)" to "Unknown error". In this case instead of "Unknown error" something like "The error trace pattern has an unsupported format" can be more appropriate.

At least, it is very easy to add some short instruction.

But yes, without an instruction it may be hard to understand what is the appropriate error trace pattern format.

#4

Updated by Vitaly Mordan about 3 years ago

Evgeny Novikov wrote:

This is actually a very good design since it allows to find and to report the root problem.

The user, who sees it for the first time, will simply ignore the issue, since it it impossible to report or inspect the problem (several different errors are replaced with useless "Unknown error").
The user, who more or less understands, what he is doing, may get unexpected result.

This is a bad design. Calling it a "good design" is absurd at least. Or you do not understand, why this functionality is required and how it should be used.

#5

Updated by Vladimir Gratinskiy about 3 years ago

Vitaly Mordan wrote:

Evgeny Novikov wrote:

This is actually a very good design since it allows to find and to report the root problem.

The user, who sees it for the first time, will simply ignore the issue, since it it impossible to report or inspect the problem (several different errors are replaced with useless "Unknown error").
The user, who more or less understands, what he is doing, may get unexpected result.

The user who less understands what he is doing shouldn't use Bridge at all. Especially edit converted error traces. The one who want to change converted error trace definitely should understand what format of converted traces Bridge provides. "Unknown error" was designed for "stupid" and unexpected actions that user can do. I can't check all cases of wrong actions and provide good error message for each of them. It is ugly in code, IMHO.

#6

Updated by Vitaly Mordan about 3 years ago

Vladimir Gratinskiy wrote:

The user who less understands what he is doing shouldn't use Bridge at all.

But if he is using it, we need to point him on possible solution (for example, "incorrect format of error trace pattern, see correct format there").

The one who want to change converted error trace definitely should understand what format of converted traces Bridge provides.

He also may need short description of such format, because this format is not well known and can be changed in the future.

#7

Updated by Vladimir Gratinskiy about 3 years ago

Vitaly Mordan wrote:

He also may need short description of such format, because this format is not well known and can be changed in the future.

Then this "bug" is subtask of #7307.

#8

Updated by Evgeny Novikov about 3 years ago

  • Tracker changed from Bug to Feature
  • Subject changed from Editing converted error trace does not work (as expected) to Add how to edit converted error traces
  • Description updated (diff)

Vladimir Gratinskiy wrote:

Vitaly Mordan wrote:

He also may need short description of such format, because this format is not well known and can be changed in the future.

Then this "bug" is subtask of #7307.

This isn't a subtask, but without that issue this one won't be implemented.

#9

Updated by Evgeny Novikov about 3 years ago

Vitaly Mordan wrote:

Evgeny Novikov wrote:

This is actually a very good design since it allows to find and to report the root problem.

The user, who sees it for the first time, will simply ignore the issue, since it it impossible to report or inspect the problem (several different errors are replaced with useless "Unknown error").
The user, who more or less understands, what he is doing, may get unexpected result.

This is a bad design. Calling it a "good design" is absurd at least. Or you do not understand, why this functionality is required and how it should be used.

Such the errors shouldn't happen in production while if one will use development settings for Bridge then one will get very many details on errors.

What interesting for me here is that Bridge can automatically rollback changes that can result in entities have incorrect formats. This is already done for unknown marks where you can't specify incorrect regular expressions. This also should be done for editing converted error traces.

#10

Updated by Vitaly Mordan about 3 years ago

  • Subject changed from Add how to edit converted error traces to Add description about converted error traces format
#11

Updated by Vitaly Mordan about 3 years ago

Evgeny Novikov wrote:

Such the errors shouldn't happen in production while if one will use development settings for Bridge then one will get very many details on errors.

Bad design is bad design even in master, there is a lot of "poorly established code" there, which needs to be refactored or improved for production. If you would act like in #7617, most of the code should be deleted immediately.

What interesting for me here is that Bridge can automatically rollback changes that can result in entities have incorrect formats. This is already done for unknown marks where you can't specify incorrect regular expressions. This also should be done for editing converted error traces.

This will be much more harder to implement. Also if it will be implemented with the same "Unknown errors", it will not be more useful than adding some simple instruction.

#12

Updated by Vitaly Mordan about 3 years ago

  • Priority changed from Normal to High
#13

Updated by Vitaly Mordan about 3 years ago

  • Description updated (diff)
#14

Updated by Vitaly Mordan about 3 years ago

More harder to implement functionality (e.g., report correct errors or prevent the user from saving incorrect format) is placed in #7915.

#15

Updated by Evgeny Novikov about 3 years ago

  • Category changed from Bridge to Documentation
  • Assignee set to Vladimir Gratinskiy

As with other help pages (see issues connected to #7307), please, add a wiki page for preliminary discussion. Further it will be incorporated into Bridge.

#16

Updated by Evgeny Novikov over 2 years ago

  • Status changed from New to Closed

This was done in Klever 0.2.

Also available in: Atom PDF