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, we would need to extend Hex-Rays to support things like try/catch/finally blocks as scoped constructs. This seems especially tricky for third-party developers, as it involves substantial changes to the ctree representation that Hex-Rays uses internally.

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.

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 try/catch/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 enum called ctype_t. We'd need to add new entries like cit_try to this enum, we'd need to extend the union in 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.