Feature #7908
closedAdd description about converted error traces format
Added by Vitaly Mordan almost 8 years ago. Updated about 7 years ago.
0%
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.
Updated by Evgeny Novikov almost 8 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.
Updated by Vitaly Mordan almost 8 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.
Updated by Evgeny Novikov almost 8 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.
Updated by Vitaly Mordan almost 8 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.
Updated by Vladimir Gratinskiy almost 8 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.
Updated by Vitaly Mordan almost 8 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.
Updated by Vladimir Gratinskiy almost 8 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.
Updated by Evgeny Novikov almost 8 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.
Updated by Evgeny Novikov almost 8 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.
Updated by Vitaly Mordan almost 8 years ago
- Subject changed from Add how to edit converted error traces to Add description about converted error traces format
Updated by Vitaly Mordan almost 8 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.
Updated by Vitaly Mordan almost 8 years ago
- Priority changed from Normal to High
Updated by Vitaly Mordan almost 8 years ago
More harder to implement functionality (e.g., report correct errors or prevent the user from saving incorrect format) is placed in #7915.
Updated by Evgeny Novikov almost 8 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.
Updated by Evgeny Novikov about 7 years ago
- Status changed from New to Closed
This was done in Klever 0.2.