An error should be reported loud indeed, but it shouldn't fail hard, as it depends on the nature of the error.
I think perhaps we are operating under differing definitions of the term 'error'.
I generally define 'error' as any event with risk of data loss or security breach - artist placing mesh in the wrong place seems at worst to be some sort of validation warning.
I agree. The points I was trying to make were more about daily production and how to deal with bad data or when some assumption in your algorithm is not satisfied.
FWIW, in my professional experience, crashing on assertion failure (if a debugger isnt attached) is very common.
I recommend to rethink this. I do quite some interviewing these days and saying something like this in an phone screen or interview would be a dark red flag. I don't know what experience you have in professional development, but maybe don't think so much shipping, but daily development in large teams of maybe 100 people. If you crash loud and hard on every little bug because of not programming defensively I don't see such a team working effectively.ail fast and fail loud, there is no other way
Continuing after an assertion is such a brilliant idea, what could possibly go wrong by running the program in an invalid state..
From personal experience: I worked under a "senior" developer who thought allowing the user to continue after assertions and unhandled exceptions (..) was a good idea. I don't remember one day where I didn't waste my time investigating bogus bug reports that only existed because of invalid state. Seriously, fuck that.
Sure, I don't think it is a good idea sending bug reports after you decided to ignore an assert. I didn't advocate this.
Maybe an example to keep things less abstract: I recently wrote a Maya plugin for our physics engine Rubikon. In the solver I compute values which are supposed to be larger zero. This is an invariant so I enforce it with an assertion. If I would crash in that case this would shut down Maya and the artist would have lost all his work. The only thing that should happen (in my opinion!) is that the simulation looks bogus and he resets the scene and can ask me what went wrong. The assert gives me a hint to identify the problem. I walk over his desk, have a look with him and fix his scene. Then I fix the bug that led to the assertion by catching wrong user input much earlier (e.g. by ignoring the invalid constraint when building the scene and give a proper warning) and the problem is solved.
I don't want to be pedantic about assertions. Having a similar macro (e.g. Verify) would be totally fine with me. Then we can have assertions for the case where things get into a really bad state (e.g. memory corruption). It might arguable if the extra complexity with several macros buys you anything. Probably a matter of personal taste.
The error was not court where it happened and went down the chain till it found a try catch block.
You are aware that you can set your debugger to break whenever an exception is thrown (not just when it is caught)?
You are aware that you can set your debugger to break whenever an exception is thrown
Umm no I did not. Im new to the whole exception thing forced(not really boost allows you to pass a error class boost::system::error_code& ec to functions).
We did learn about them in class some 20 years ago, just forgot never used them, did not like it at the time and never thought of it again until yesterday.
Search through the code base for boost::uuids::string_generator found this
.
boost::uuids::string_generator gen;
boost::uuids::uuid u1 = gen(appguid);
.
Where appguid on client that never finnished connecting can be NULL. Totally my fault for thinking I'll get the supported app class done quick and no error checking needed.
Which goes against the protocol I set for that very reason in the past, But every so often I breach that for what ever reason who knows.
