New feature: Error reporting

[donnyv]

I use the library with files I have no control over. I really need a way to get at deeper error messages in the lib. Returning a null is just not cutting it. If I provide a PR with a way to return those messages are you open to accepting that? I don't want to fork the project. But I also don't want to do all this work and then it doesn't get accepted. Obviously I don't expect it to be accepted unless it meets your standards. But are you open to this new feature?

[haplokuon]

This has been asked in other occasion. Read this first, since them nobody else posted about it.

The problem with this is that building an understandable and usable error message system is not that straight forward. I do not know how you intend to implement what you propose. Just showing the exception generated due to an internal error when a file loaded is not enough, it can be pure gibberish if you are not very familiar with the DXF format, or even the origin of the problem begun several steps earlier, sometimes it can be hard to track. The exceptions and assertions generated by the Debug build of the library when loading a DXF are really only for me to hunt for bugs and nobody else.

The actual DXF loader is very stable, it doesn't mean that it is absolutely free of bugs, but it should never return null if the DXF is good, unless there is a critical bug and in such cases I will always need to take look at the file personally, no kind of error message, no matter how detailed it might be, will be a substitution from actually testing the problematic file. If a user comes with an issue not willing or cannot supply a sample, or the problem is simple, or, sorry, I cannot do anything for you. No error system will substitute the file, so I still hold to my words, implementing this is not worth the hassle. The DXF is so loosely structured, there are so many crappy DXF writers around, and the documentation so awful that anything can happen. I do not know any program, apart from AutoCAD, that shows any meaningful message when loading bad DXF just a the typical "File cannot be loaded" when you are lucky, and this is extensible to many other programs. Even AutoCAD do not show errors for every kind of problem it may occur, even it does the worst thing a program can do, crashing when loading a file, and it does this a lot specially with problems with the handles.

Lately very few real bugs have been reported, and all of them have been fixed. Most of the issues comes from bad DXFs, but sometimes they even come from people using nuget packages, they are not mine, those versions are old, very old. DO NOT USE THEM, unless its owner updates them. As I wrote in another post I will not provide compiled versions of this library anymore, so if you haven't compile it yourself from the source code it is no mine. So, if when loading a DXF file with the Release build it returns null, most probably is a bad file and there is nothing you can do. It is not like someone can just manually edit the DXF to fix it, because you knew the exception. Me, as a user, if I run into this kind of things with other software, the file goes into the bin, or the program if I am 100% sure that the file is valid.

You said that you have no control over the DXF file, but I guess, if someone reports to you that a DXF could not be loaded, at the very least, they can provide you with a sample to check it out. I do not know how familiar you are with the DXF format; but, if you are, run the file with the Debug build and much better with the source code.

[donnyv]

I think you under estimate how useful those DEBUG lines are. As you know a lot can go wrong with a DXF file. I have ran the project in debug in Visual Studio to find out why a DXF can't be opened. These are some of the issues I've run across.

1. Layer contains characters in layer name that are not valid. => It would be useful to get all the layer names that have invalid characters so that the user can purge these on their side or know which ones need to be fixed.
2. When ever something is missing that something else needs it usually has the name in the error. Like a linetype or layername or table or handle, etc. => Again this would be handy because I could pass this to the user and they would then know what to look for to clean up the drawing.
3. Missing shp file => If the user sees this then they will at least know to provide it or remove the reference from the dxf.

A lot of times AutoCAD is just as bad as other apps that write out dxf files. I just recently had a drawing that had a " | " in one of the layer names. This drawing originally came from a DGN, then converted to DWG and then finally converted to DXF. The whole time AutoCAD never flagged the layer name, even though the character is invalid.

I think just the 3 items above would cut down a lot on people posting questions here. Since they could see what the error is and how to possibly track it down and fix it.

[DavidWishengrad]

I understand both your points. Daniel's point regarding opening the file in source and debug is a stronger point to an additional utility that will never handle everything and tell you everything. I have not attempted to fix and/or find an error in a dxf in years and if I need to do that I can just load it via code and the exact error or errors will probably pop right up. I don't understand how anything can be better than that. He's already done the best. If someone wants a simple utility that does less based on his work then should make it. I don't see the time in coding vs time using the functionality really worth it, being as one only needs to load visual studio, run the code and load the dxf. Just my 2cents

[donnyv]

I think you don't understand what I'm trying to say here. By bubbling up those errors into the app level. Whether by an exception or returning it after Load() is called. These errors could be then reported back to the user using the app, thats using the dxf lib. The user could then update the dxf and fix those problems. This removes the need for a developer to run a clients dxf in debug mode and also alleviates bug reports for @haplokuon