Solved

Suppress annoying WARN messages of AutoCAD FeatureReader?

  • 23 March 2023
  • 6 replies
  • 12 views
L

Is there a possibility to suppress annoying WARN messages of the 'Autodesk AutoCAD RealDWG DWG/DXF' FeatureReader?

 

Please see the following example:

I use the AutoCAD reader to read features from an DWG file. I am only interested in the features of one specific layer (specified by a user parameter):

imageHence, the AutoCAD reader reads the file and skips all layers but the specified one.

 

In the log, the reader starts writing which layers are skipped. These messages are written at 'Information' level. After writing the 10th skip message, it writes a message "Further instances of this message will be suppressed" on WARN level.

-----

imageAs text:

2023-03-23 14:17:38|  1.8| 0.0|INFORM|AutoCAD Reader: Successfully opened the 'Release2018' AutoCAD file '<SOME_PATH>'

2023-03-23 14:17:38|  1.9| 0.1|INFORM|AutoCAD Reader: Features for feature type '0' will be skipped based on the feature types requested

2023-03-23 14:17:38|  1.9| 0.0|INFORM|AutoCAD Reader: Features for feature type 'A_19_BESTAND_SCHR' will be skipped based on the feature types requested

2023-03-23 14:17:38|  1.9| 0.0|INFORM|AutoCAD Reader: Features for feature type 'A_301_ADTRAUM' will be skipped based on the feature types requested

2023-03-23 14:17:38|  1.9| 0.0|INFORM|AutoCAD Reader: Features for feature type 'A_301_ADTRAUM_BS' will be skipped based on the feature types requested

2023-03-23 14:17:38|  1.9| 0.0|INFORM|AutoCAD Reader: Features for feature type 'A_02_LEICHTWAND_SCHR' will be skipped based on the feature types requested

2023-03-23 14:17:38|  1.9| 0.0|INFORM|AutoCAD Reader: Features for feature type 'A_014_STUETZE' will be skipped based on the feature types requested

2023-03-23 14:17:38|  1.9| 0.0|INFORM|AutoCAD Reader: Features for feature type 'A_19_BESTAND' will be skipped based on the feature types requested

2023-03-23 14:17:38|  1.9| 0.0|INFORM|AutoCAD Reader: Features for feature type 'A_68_BAUM' will be skipped based on the feature types requested

2023-03-23 14:17:38|  1.9| 0.0|INFORM|AutoCAD Reader: Features for feature type 'Z_00_EINFUEGEPKT' will be skipped based on the feature types requested

2023-03-23 14:17:38|  1.9| 0.0|INFORM|AutoCAD Reader: Features for feature type 'A_013_TUER' will be skipped based on the feature types requested

2023-03-23 14:17:38|  1.9| 0.0|WARN |Further instances of this message will be suppressed

-----

 

I try to keep my workspaces free of WARN messages, so this is very annoying since I do not see a possibility to get rid of these WARN messages.

 

Is there any option in the AutoCAD FeatureReader to suppress these kind of messages?

icon

Best answer by david_r 24 March 2023, 12:00

View original

6 replies

david_r
Rank
Userlevel 4

Not that I'd recommend it, but you can effectively remove specific log messages by editing the text file <FME HOME>\\messages\\fmemessages.fms

Do not delete the line, rather just remove everything after the first comma, e.g.

imageYou'll still get the final warning about "Further instances of this message will be suppressed", however, unless you remove that one as well -- which I'd really recommend against, as it's used in many different situations.

If you want to remove all WARN messages regardless of the contents, you can disable them in the FME Options.

L

Hi @david_r​,

thank you for your answer and this interesting hint.

 

The single specific log messages in the form of

 

2023-03-23 14:17:38|  1.9| 0.1|INFORM|AutoCAD Reader: Features for feature type '0' will be skipped based on the feature types requested

 

are ok for me, though, no need to remove them.

 

I wouldn't even mind if they would not be skipped after the 10th message of the same kind. Is there a setting such that the number after which the final warning is written might be increased from 10 to e.g. 100 messages of the same kind? That might be feasible solution for me as well.

 

Generally, I want to achieve my superordinate goal of the translation log showing 0 warnings at the end of a successful translation in a "clean" way, not by artificially suppressing reasonable WARN messages.

 

I mean, since I configured in the FeatureReader that I am only interested in features of a specific layer/a specific feature type, in my opinion, there is no need for the FeatureReader to spam the log with information about that the features of all these other feature types are skipped and finally even create a WARN message because there are so many skipped feature types.

It is even totally unnecessary because I explicitly configured the FeatureReader this way and am fully aware of it, and it prevents me from designing a "clean" workspace with 0 warnings (which should be the goal for a workspace designer, right? I see it as analogous to writing code with 0 code smells.). At least, it should be made configurable if the FeatureReader should inform about skipped feature types (yes, it's certainly nitpicky).

david_r
Rank
Userlevel 4

Hi @david_r​,

thank you for your answer and this interesting hint.

 

The single specific log messages in the form of

 

2023-03-23 14:17:38|  1.9| 0.1|INFORM|AutoCAD Reader: Features for feature type '0' will be skipped based on the feature types requested

 

are ok for me, though, no need to remove them.

 

I wouldn't even mind if they would not be skipped after the 10th message of the same kind. Is there a setting such that the number after which the final warning is written might be increased from 10 to e.g. 100 messages of the same kind? That might be feasible solution for me as well.

 

Generally, I want to achieve my superordinate goal of the translation log showing 0 warnings at the end of a successful translation in a "clean" way, not by artificially suppressing reasonable WARN messages.

 

I mean, since I configured in the FeatureReader that I am only interested in features of a specific layer/a specific feature type, in my opinion, there is no need for the FeatureReader to spam the log with information about that the features of all these other feature types are skipped and finally even create a WARN message because there are so many skipped feature types.

It is even totally unnecessary because I explicitly configured the FeatureReader this way and am fully aware of it, and it prevents me from designing a "clean" workspace with 0 warnings (which should be the goal for a workspace designer, right? I see it as analogous to writing code with 0 code smells.). At least, it should be made configurable if the FeatureReader should inform about skipped feature types (yes, it's certainly nitpicky).

I understand where you're coming from, but I'm not sure it's very helpful to compare log warnings with code smell: you have very limited ways to influence what is logged, and messages that are irrelevant to you may be critical to other use cases. Have you considered using the LogMessageStreamer to filter the contents to your own, custom log file?

I had a look around to see if it was possible to configure the number of repeated log entries before they're collapse into a single message, but couldn't find anything.

virtualcitymatt
Rank
Userlevel 4
Badge +26

This seems a bit like a bug, it probably shouldn't be being logged as a warning given it's content. That being said, there are a tonne of reasons why FME would log warnings which can safely be ignored. Trying to write workspaces which avoid warnings can be pretty annoying and, in my opinion, is not really worth it. This is particularly common when trying to build dynamic workflows which may or may not do particular things depending on the data, or when a bad data feature that the workspace developer can't control gets into the workflow. FME can fix the bad data perhaps but may log a warning about it.

Depending on who you talk to as well there are ERRORS which some would prefer logged as warnings and warnings which they'd prefer to be ERRORS.

 

 

L

I understand where you're coming from, but I'm not sure it's very helpful to compare log warnings with code smell: you have very limited ways to influence what is logged, and messages that are irrelevant to you may be critical to other use cases. Have you considered using the LogMessageStreamer to filter the contents to your own, custom log file?

I had a look around to see if it was possible to configure the number of repeated log entries before they're collapse into a single message, but couldn't find anything.

Right now, my use-case does not require creating a custom log file, it really just is focused on the manually running a translation via FME. However, in the future, there a plans for an automatic execution with FME server, and in this context, the LogMessageStreamer transformer looks like to could be really useful. So thank you very much for this hint!

 

The comparison with a code smell was a bit exaggerated, I agree. I was annoyed with this WARN message because in the given context, it does not make sense to me. To generally please everyone with the granularity of the log levels is certainly very difficult (as also @virtualcitymatt​ pointed out).

 

I think I'll leave it as it is for now and when used with FME Server, I'll have a deeper look at the LogMessageStreamer. Thanks again for your valuable answers @david_r​.

 

L

This seems a bit like a bug, it probably shouldn't be being logged as a warning given it's content. That being said, there are a tonne of reasons why FME would log warnings which can safely be ignored. Trying to write workspaces which avoid warnings can be pretty annoying and, in my opinion, is not really worth it. This is particularly common when trying to build dynamic workflows which may or may not do particular things depending on the data, or when a bad data feature that the workspace developer can't control gets into the workflow. FME can fix the bad data perhaps but may log a warning about it.

Depending on who you talk to as well there are ERRORS which some would prefer logged as warnings and warnings which they'd prefer to be ERRORS.

 

 

Thanks for your answer @virtualcitymatt​. Seems like it really is a bit too ambitious to resolve each and every occuring WARN message. I just found that often, the WARN messages are good indicators that a suboptimal/questionable way to solve the given task was chosen and therefore, fixing them actually improved my workspaces quite a bit.

Reply


Community Stats

28,716
Posts
109,494
Replies
36,561
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.