Error handling policies

[iwbnwif]

Subtopic moved from #12 because this refers to an enhancement whereas the rest were just questions.

Lastly, just one little request ... can we have asserts instead of exceptions please ?!!!

Not so little, but perhaps should be allowed. Perhaps "policies" could be introduced for error handling. You might pass one in so that your app can deal with errors however it chooses?

This sounds like an excellent idea.

Might I ask why you want errors handled as asserts?

Possibly this is due to my lack of C++ knowledge, so please correct me because I may completely misunderstand a very basic point about exceptions ...

I tend to use gcc / gdb on Linux and their MinGW64 ports on Windows.

The default behavior of gdb [seems to be] when it gets an unhandled exception to terminate with no message, no stack trace, no clue whatsoever. On the other hand an assert suspends the execution at exactly the place where the assert occurred and provides a call stack up to that point.

Perhaps, I should just be catching exceptions at the highest level, but I still don't think I will get a call stack to the line that caused the exception? Also I am using other libraries which have exceptions, then it is hard to know which library threw the exception.

So the result is that I have to wrap every Ponder call with try / catch, even if it is just one line. I guess that makes sense in production so as not to leave the program in an indeterminate state or with incorrect values but for debugging it is a bit of a nightmare ;-). Even in production, one missed try / catch could cause sudden, unexplained program closure?

[billyquith]

But then what would happen if you put asserts in? You'd get the same result, and no way to catch the error and perhaps recover.

You can put a try-catch handler at a high level point in your code after which point you use Ponder. If you are getting any exceptions it is because there is a bug in your app logic or type registration, e.g. a wrong name etc. Here you can print out the exception details and fix it.

I haven't use gdb for a long time and I can't remember how it works. You might try the free Visual Studio 2015 offering. Not a bad IDE for free.

[billyquith]

I'm going to close this for now as I think exceptions is the right solution for now. The main downside is performance of them, but they just shouldn't be firing unless there is a bug, which will need fixing.

[iwbnwif]

Firstly, thank you for all the other enhancements. I haven't tried them yet but will do soon.

I am working on Linux so a bit stuck with gdb, but anyway this is certainly something I can live with given all the other great things about Ponder.

All the 'Ponder heavy' sections are now wrapped in try .. catch, it's just the odd Value::To<> one liners like:

int length = uLength.To<int>();

where I would prefer to assert - and fix - rather than wrap every one in try .. catch.

Having said that, the beauty of open source is that I can always look at replacing PONDER_ERROR with my own version in my local copy :)