I've considered doing this myself, but it's tricky for many reasons.
First, exception internals are not standardized across languages, platforms, or implementations. 64-bit Windows programs use a data-driven exception model, i.e., the
RUNTIME_FUNCTION (etc.) entries in the
.rdata segment. In this paradigm, the binary pre-registers information about exception scopes and handlers with the operating system via standardized structures, which takes care of lookup and dispatch when an exception occurs. Your example shows 32-bit Delphi; 32-bit Windows programs use a code-driven exception model, where the code is responsible for adding and removing exception handlers on demand, using proprietary metadata formats. As a result, adding exception support would require a lot of platform and language-specific effort, and may involve reverse engineering undocumented exception implementations across multiple runtime versions for a given language. While there would be benefits to adding exception support, it would also require a lot of work to develop (and maintain as the runtime support evolves over time).
Secondly, even if we were to decompile exception-related things into a simplified, language-independent representation, the most logical method of presentation would involve extending Hex-Rays to support things like
finally blocks as scoped constructs, and producing these things in the output. Unfortunately, extending the Hex-Rays
ctree IR in this fashion is impossible for third-party developers. The valid
ctree expression types are held in an
ctype_t. We'd need to add new entries like
cit_try to this
enum, we'd need to extend the
cinsn_t to support an additional
ctry_t * element, and we'd need to modify all of the existing
ctree code in Hex-Rays to be aware of our modifications (for example, to print the
try blocks in the decompilation listing). None of these things can be done by third-party plugins, as the existing, pre-compiled code will generate INTERRs upon encountering our
cit_try instructions. Adding statement types to the
ctree IR can only be accomplished via source-level modifications, not via plugins.
Finally, even though Hex-Rays technically has an option not to eliminate exception-related code, I'm not completely sure how it works. Exception-related code often manifests itself as "function chunks" attached to a given function, which have no incoming control flow references. As a result, that code is eliminated by the optimizer very early into the decompilation process. You'd need to find a way to preserve it.
It's a daunting prospect for a third-party developer; I myself abandoned the idea. It's also daunting for the first-party developers. I don't expect to see it in any major decompiler any time soon.