Sorry about going dark, I just been busy with life and tying to find time refactoring the polyline.
I’ve been seeing a huge amount of commits fixing broken stuff which is is nice to see.
So it’s going to be a while till I have something for users to play with the refactored polyline, When I get to that point, for some alpha testing, I’m sure that there will be stuff that will still need to be implemented.
So… that leads me to this post.
When I do development in C#, I generally with throw a non-implemented exception of some feature that needs to be built. Many times this feature isn’t needed yet, so I can leapfrog around building out most of the framework of the application. When the feature is needed, I get an non-implemented exception being thrown so I know it’s not a logic error but something needing to be coded. I see the call stack and fix it. By the time, I’m ready for user testing I have the code sections implemented or handled in the non-implemented exception so it doesn’t crash for the user. This style works fine for applications that are sucking data out of an ERP system but I could see users really getting irked if there app crashes and looses a 1/2 hour or more of work on a non-implemented feature that I missed not handling, I don’t want to inflict that pain on a user if it can be avoided.
In C# another method of handling non implemented features is that instead of throwing an exception is to a Debugger.break() in to stop the application when the IDE is running so you can see the call stack, but it continues to run otherwise. I’ve got to think there is some rough equivalent to that in qt.
Does this project have a preferred style for handling non-implemented features which won’t crash the app for the user but would break for the developer when running debug in the IDE?
@chchwy @feeef et al, I was reading exception handling behavior is not necessary consistent from platform to platform so I’m thinking my coding style for handling non-implemented methods in MS/C# style may not be appropriate for this project.
I’m anticipating/hoping that the re-factored polyline functionality will be slicker than whale doo-doo in an ice-flow, so I like to get it rolled out for alpha testing sooner than later. I think it would benefit the project if we had a standard way of handling non-implemented features. Since Qt/c++ isn’t my primary language, any advice, pearls of wisdom, thoughts for the day… etc… would be appreciated.