Index
> Compiler Internals > Feature request about "err" directive. |
| Author |
|
|
revolution 23 May 2014, 01:16
Code: if something display "Method ABC not defined. I'm giving up" err ;WTF just happened? end if |
|||
23 May 2014, 01:16 |
|
|
JohnFound 23 May 2014, 04:43
@revolution: please, detailed.
|
|||
|
23 May 2014, 04:43 |
|
|
l_inc 23 May 2014, 11:56
I was thinking about the same feature for a long time. And therefore I was a bit frustrated when assert had been introduced making the unification of both error generation features impossible in a way, that supports custom error messages.
_________________ Faith is a superposition of knowledge and fallacy |
|||
|
23 May 2014, 11:56 |
|
|
Tomasz Grysztar 23 May 2014, 14:34
One of the reasons why it was implemented this way, was that fasm always presents the complete line that has caused an error, therefore any message provided as an argument to ERR directive would usually end up being displayed twice. Also, when the ERR was implemented, it was intended to be, in a way, backwards compatible (almost like the UD2 opcode in the Intel architecture) - the older version of fasm react to it in a similar way, just the exact message differs ("illegal instruction" in old versions versus the dedicated message in the later ones).
The messages presented by fasm in the "error:" line form the closed set that equivalent to error codes returned by a function. In case of fasm.dll, each one of these messages has a dedicated code. The "user error" cased by the ERR directive is something like a general category of "other" - when something like that appears in any API, it is usual to provide additional detailed information in some other way (extended data structure, additional log, etc.). In case of fasm the most obvious way is to use the DISPLAY buffer, as revolution pointed out. |
|||
|
23 May 2014, 14:34 |
|
|
JohnFound 23 May 2014, 16:25
Tomasz Grysztar wrote: One of the reasons why it was implemented this way, was that fasm always presents the complete line that has caused an error, therefore any message provided as an argument to ERR directive would usually end up being displayed twice. But in the present implementation, the error message does not contains information about the causes of the error. Only about the fact that the compilation stopped. It is of course normal and expected, because the compiler can't know what caused the error. Only the user can. In this case, it is better to display something twice than not display it at all. And one possible solution to this is to not display the row of the source, if the error is generated by "err" - in all cases, it does not carry any useful information, only the word "err". Using of the "display" directive works, as I already demonstrated, but the solution ends with two error messages, one of them not useful at all. One another solution is to simply ignore the whole text after the "err" directive and to make "err" directive to display very short message, like: "User error:" or simply "Error:". (Now an attempt to set string after err, leads to "extra characters on line"). But imho, it is dirty solution. BTW, the "assert" directive makes the things even worse, because in this case, if more than one display directive is used in the source, the user displayed error message (by display directive) can be separated from the assert generated error message with many rows of other text, generated in the last pass. _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
|
23 May 2014, 16:25 |
|
|
revolution 23 May 2014, 16:32
JohnFound wrote: And one possible solution to this is to not display the row of the source, if the error is generated by "err" - in all cases, it does not carry any useful information, only the word "err". Code: err ;This comment is also printed to the output |
|||
|
23 May 2014, 16:32 |
|
|
JohnFound 23 May 2014, 16:37
@revolution - It will not, because the displayed code line is restored from the preprocessed code, but there is no comments anymore.
|
|||
|
23 May 2014, 16:37 |
|
|
revolution 23 May 2014, 16:39
JohnFound wrote: @revolution - It will not, because the displayed code line is restored from the preprocessed code, but there is no comments anymore. Code: flat assembler version 1.71.20 (960953 kilobytes memory) err.asm [1]: err ;help error: error directive encountered in source file. |
|||
|
23 May 2014, 16:39 |
|
|
JohnFound 23 May 2014, 16:49
Strange. Not working in FASMW. Probably the console versions use another approach. But it is not so, important. More important is that in the comments you can't use preprocessor symbols that to be replaced with it's values - see the examples in my first post.
|
|||
|
23 May 2014, 16:49 |
|
|
revolution 23 May 2014, 16:51
JohnFound wrote: Strange. Not working in FASMW.
|
||||||||||
|
23 May 2014, 16:51 |
|
|||||||||
|
JohnFound 23 May 2014, 17:08
Yes revolution, my as well. And Fresh IDE have the same behavior. But this fact does not solves the problem. And yes, I can see where the error is and can gather enough information in order to solve it. It is not a bug and as such does not need "fixing".
But it can be more user friendly and useful. It can improve the user experience. That is why I am asking about it as a "feature request". Or you think "Error: error directive encountered in source file" is good and informative error message? It is actually captain Obvious replica, not an error message. |
|||
|
23 May 2014, 17:08 |
|
|
l_inc 23 May 2014, 19:52
Tomasz Grysztar
Quote: therefore any message provided as an argument to ERR directive would usually end up being displayed twice This one sounds convincing and I was thinking about adjusting the err functionality in a way that it ignores the remaining tokens on line, so that the "extra characters on line" is not displayed instead. But I find the JohnFound's suggestion to refrain from displaying the err line more sensible. I completely agree with him, that the err line in the error log does not carry any useful information. Quote: when the ERR was implemented, it was intended to be, in a way, backwards compatible If I understand you correctly "backward compatibility" is here the possibility to use older versions of fasm in order to compile source codes for newer ones, right? I don't think, it makes any sense at all, because this kind of "backward compatibility" would be limited to very few fasm directives (any except err ?), and nearly any other feature of the newer versions would cause compilation failures. Why would someone at all write code for older fasm versions using a newer fasm? It's not even near the CPU story, when a company writes software using brand new Skylake's, but knows, that the majority of their users have SandyBridge's and some might still have NetBurst's to run the software. The forward compatibility — the possibility to compile older source codes with newer fasm versions — is here much more important, but is broken anyway: e.g. it was possible to define a numeric constant with the name err before, and now this would fail to compile. Quote: The "user error" cased by the ERR directive is something like a general category of "other" - when something like that appears in any API, it is usual to provide additional detailed information in some other way I'm missing the point, where the err directive was somehow unlucky to become this "some other way". A user-generated error is something somewhat unique and special to the closed set of errors anyway. What bothers me in this story is the necessity to have multiple lines, when using the err or assert directive. I often need something like match ,arg { err "Argument value is missing" }, because an additional display makes me spread this line across five lines while obeying rules of my coding style. But I think it's too late to fix this now, because the incompatible syntax of the assert directive makes the fix incomplete. The feature is obviously not vital and display is again obviously a way to go. There's just one more unfortunate design decision. Fortunately, a quite harmless one. A humble opinion. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
23 May 2014, 19:52 |
|
|
Tomasz Grysztar 23 May 2014, 23:09
l_inc wrote: If I understand you correctly "backward compatibility" is here the possibility to use older versions of fasm in order to compile source codes for newer ones, right? I don't think, it makes any sense at all, because this kind of "backward compatibility" would be limited to very few fasm directives (any except err ?), and nearly any other feature of the newer versions would cause compilation failures. Why would someone at all write code for older fasm versions using a newer fasm? So when I implemented the ERR as a special directive, it did not really change much in how these old macros worked, it just made it a bit more "formal", per request. l_inc wrote: I'm missing the point, where the err directive was somehow unlucky to become this "some other way". A user-generated error is something somewhat unique and special to the closed set of errors anyway. l_inc wrote: What bothers me in this story is the necessity to have multiple lines, when using the err or assert directive. I often need something like match ,arg { err "Argument value is missing" }, because an additional display makes me spread this line across five lines while obeying rules of my coding style. |
|||
|
23 May 2014, 23:09 |
|
|
l_inc 23 May 2014, 23:32
Tomasz Grysztar
Quote: it did not really change much in how these old macros worked Allowing an optional string argument would not change anything either. Quote: What I meant was that it is usual in API to have a code that means "other kind of error, see ... for more information, where "..." needs to be some additional data structure" I understand that. And what I meant was that "..." could actually be an optional argument of the err directive. Or is there some point in making it harder to fill that "additional data structure"? Quote: I think that you in fact gave a very good example of how ERR can be used But the output is not good enough. That is why I was originally thinking of an explicit ignoring of the remaining tokens on line, but ... (see the first paragraph of my previous post  )
But again, just to be clear. I'm not trying to convince you, that the subject is good to implement now. Mainly because I think, that err and assert should have a uniform syntax, and it's now too late for assert. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
23 May 2014, 23:32 |
|
< Last Thread | Next Thread > |
Forum Rules:
|