walter-erquinigo wrote: > Exception Breakpoints are created by the static method > LanguageRuntime::CreateExceptionBreakpoint. So they don't require a process.
Indeed, but let me elaborate. What I need is a method that doesn't require a process that could tell me if a certain language can support exception breakpoints, as that's what the checks in the `breakpoint set -E <lang>` command try to do. Then I had two main choices w.r.t `LanguageRuntime`: - Add the method as non-static `LanguageRuntime`, but `LanguageRuntime` instances do require a process. - Add a static method in `LanguageRuntime`, like `CreateExceptionBreakpoint`, but it turns out that `CreateExceptionBreakpoint` ends up relying on `Language::GetDefaultExceptionResolverDescription` and `Language::GetExceptionResolverDescription`. So this made me believe that it'd be better to place all the static exception feature bits in `Language` and not `LanguageRuntime`. `LanguageRuntime` seems to be a place more suited for dealing with runtime behaviors and not static pieces of information. > It's a little awkward to have a static method in LanguageRuntime that makes > the Exception breakpoint conditioned by a Language method > 'SupportsExceptionBreakpoint". I somewhat agree with it, but probably I'd end up writing a static method `LanguageRuntime::SupportsExceptionBreakpoint` that invokes a non-static `Language::SupportsExceptionBreakpoint`. And as I mentioned, there's already precedent for other exception related stuff in `Language`. https://github.com/llvm/llvm-project/pull/97675 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
