# IFC import implementations with no warnings **URL:** \ **Category:** Developers\ **Created:** [February 19, 2019, 9:54pm UTC](https://forums.buildingsmart.org/t/ifc-import-implementations-with-no-warnings/1050 "2019-02-19T21:54:45Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![jonm](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/jonm/32/16_2.png) [@jonm](https://forums.buildingsmart.org/u/jonm)\ **Post date:** [February 19, 2019, 9:54pm UTC](https://forums.buildingsmart.org/t/ifc-import-implementations-with-no-warnings/1050/1 "2019-02-19T21:54:45Z")
I’m going to have a short rant here (noting that my own implementations relating to this aren’t perfect). Why are viewers in particular so poor at providing feedback to users when the IFC is not compliant with their implementation? Refer to this question here: > **[ggRhinoIFC, Curved beam fixed reference](https://discourse.mcneel.com/t/ggrhinoifc-curved-beam-fixed-reference/79004)** > > I would like to sweep a beam having a cross-section along a non-circular curve using the IFCFIXEDREFERENCESWEPTAREASOLID representation. I tried opening the IFC, from the Grasshopper example ‘Curved beam fixed reference’, with Viewers that support... Minimum the receiving application should report that the model view definition is not supported, or that some entities weren’t recognized or capable of being displayed instead of just swallowing the issue and leaving the user unaware. What can we do to improve this situation? Thanks, Jon ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [February 20, 2019, 4:21am UTC](https://forums.buildingsmart.org/t/ifc-import-implementations-with-no-warnings/1050/2 "2019-02-20T04:21:35Z")
+1. Most specifications for programming languages specify error handling behaviour.