Feature #1473
Improve tracing of exceptions in integration computations
| Status: | New | Start date: | 06/06/2015 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assigned To: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | - | |||
| Duration: |
Description
In #1472, I realised that it is quite hard to backtrace the origin of an exception which is thrown during integration. The reason is that the function calling the integral is not logged in the thrown exception. I therefore propose to put the calls of integral.romberg() in try-catch statements to properly throw the exception of the integral and additionally print out the function which called the integral, e.g. “GResponse: ERROR in GIntegral::romberg()...”
I am not sure if this is doable with the current structure but would help to find the origin of an error much quicker.
Recurrence
No recurrence.
History
#1
Updated by Knödlseder Jürgen almost 9 years ago
Well, this would lead to quite a bunch of try-catch statements as integration is now widely used.
I agree that error tracing is not easy. I’m not sure whether one could somehow access the entire stack trace?
#2
Updated by Knödlseder Jürgen almost 9 years ago
Maybe something like that: http://stackoverflow.com/questions/77005/how-to-generate-a-stacktrace-when-my-gcc-c-app-crashes
Note that this is however system dependent, hence it has to be made sure that this would work on all supported platforms.
#3
Updated by Mayer Michael almost 9 years ago
I agree that the try-catch statements are not a well-elaborated suggestion.
When adding a complete stack trace for each exception, the error might not be well readable any more for the user. Maybe we have to think about this more for what cases we want a deeper track of the origin of the exception.