How to debug an unhandled exception

ekutter, yes you did explicitly mention calls that are "supposed" to return exceptions. My bad. I have to wonder if everyone even catches the exception that I mentioned, as I've heard reports of 3rd party data fields failing when two of them try to connect to the same Stryd power meter.... Exception handling can be nice when you have nested function calls that can fail at several points, all leading to a similar class of error (e.g. "Invalid input".) It avoids having to write the same return value-checking code over and over again. I would've used exceptions in that case, except as I said, it just took too much memory, so I used an archaic global error flag instead. I think indicating (recoverable) errors by return codes vs. exceptions each have pros and cons. It would be very annoying if something like String:find() threw an exception if it couldn't find the provided substring. Of course it's arguable whether that's really an "error". I'm sure something like "Property doesn't exist", as in Jim's example, is much more of a grey area with respect to "is this really an error that deserves an Exception?". Monkey C has some nice features (e.g. symbols), but it's too bad that they all come with significant overhead. I look forward to the day (far in the future) where every Garmin owner has a watch that supports 64+ KB for data fields. jim_m_58 that's actually a great example. Why would "badkey" not exist in that example? It can only be because it's a new settings key that didn't exist in a previous version of the app, right? If you never changed your app settings since the first release, you should never see that exception. If you're just using exceptions to guard against typos or other kinds of mistakes, I would argue that's a bit sloppy. I'm all for bulletproofing code using exceptions (when resources are available), but when it comes to the severely resource-constrained environment of CIQ data fields, I'm with ekutter and I prefer to try to write code that is bulletproof. (Which often fails, at least on the first try, as we all know that's impossible.)

ekutter, yes you did explicitly mention calls that are "supposed" to return exceptions. My bad. I have to wonder if everyone even catches the exception that I mentioned, as I've heard reports of 3rd party data fields failing when two of them try to connect to the same Stryd power meter.... Exception handling can be nice when you have nested function calls that can fail at several points, all leading to a similar class of error (e.g. "Invalid input".) It avoids having to write the same return value-checking code over and over again. I would've used exceptions in that case, except as I said, it just took too much memory, so I used an archaic global error flag instead. I think indicating (recoverable) errors by return codes vs. exceptions each have pros and cons. It would be very annoying if something like String:find() threw an exception if it couldn't find the provided substring. Of course it's arguable whether that's really an "error". I'm sure something like "Property doesn't exist", as in Jim's example, is much more of a grey area with respect to "is this really an error that deserves an Exception?". Monkey C has some nice features (e.g. symbols), but it's too bad that they all come with significant overhead. I look forward to the day (far in the future) where every Garmin owner has a watch that supports 64+ KB for data fields. jim_m_58 that's actually a great example. Why would "badkey" not exist in that example? It can only be because it's a new settings key that didn't exist in a previous version of the app, right? If you never changed your app settings since the first release, you should never see that exception. If you're just using exceptions to guard against typos or other kinds of mistakes, I would argue that's a bit sloppy. I'm all for bulletproofing code using exceptions (when resources are available), but when it comes to the severely resource-constrained environment of CIQ data fields, I'm with ekutter and I prefer to try to write code that is bulletproof. (Which often fails, at least on the first try, as we all know that's impossible.)