3 ms·
Maybe I’m confused about why OP is confused, but doesn’t this all just boil down to the fact that the second exception happens during the first exception so nat
by gklitz 2y ago
Maybe I’m confused about why OP is confused, but doesn’t this all just boil down to the fact that the second exception happens during the first exception so naturally the co text of the second exception contains both things “before” and after the first exception?
It feels like OP is trying to infer something aboub the source code structure which isn’t to be expected. The second “simple example” is only shown in the same order in stacktrace and code because OP ordered the functions by execution order, but that’s not a given for an actual code base, so you’ll always want to see the context of the exception thrown, and if the exception happened during handling another then you’ll see the full context.
What’s the supposed puzzle here?
- vanschelven 2y ago> doesn’t this all just boil down to the fact that the second exception happens during the first exception so naturally the co text of the second exception contains both things “before” and after the first exception? My problem is that information is removed from the stacktrace of the first exception, and that this information cannot be constructed by looking at the stacktrace. This makes it so that the first exception's "life story" begins in the middle. > because OP ordered the functions by execution order That's coincidental. I'm arguing that, in the simple example, the execution order can be inferred from the stacktrace alone. Simply by reading top to bottom. This is not true for the first example.