Summary: | [feature suggestion] Stack should be unwound and exception should be printed when a C++ application throws an uncaught exception | ||
---|---|---|---|
Product: | Base System | Reporter: | Yuri Victorovich <yuri> |
Component: | misc | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | New --- | ||
Severity: | Affects Only Me | CC: | cem |
Priority: | --- | ||
Version: | CURRENT | ||
Hardware: | Any | ||
OS: | Any |
Description
Yuri Victorovich
2019-01-17 21:28:56 UTC
I take it back. There is no general way to print exceptions when multiple languages can be present. I agree it'd be nice, and match a lot of higher level languages! Not sure what multiple languages means. If C code is compiled with -fexceptions, C++ exceptions can be raised across C libraries. I'm not sure if we do that. Probably not; we don't have a lot of C++ libraries in base. I think a similar behavior might be useful for C programs on SIGABRT. In fact, we do this (grabbing the signal-induced exit stack) at Isilon as part of coredump() in kern_sig.c, and log it to syslog. (In reply to Conrad Meyer from comment #2) I think that it isn't possible to generically catch exceptions. Even in C++ alone, object of any type can be thrown, ex. a primitive type, std::string, char* or even void*. These types can only be printed in application-specific manner. I closed this PR on the second thought. It would be nice if exception is identified as a C++ exception and printed, but I also feel that this would be kind-of a hack. But if somebody feels differently, and thinks that it makes sense to implement such special C++ exceptions handling, they are welcome to do so. :-) Yeah, that makes sense. The stack might still be useful, even without exception information? At least the stack + information about how the process exited (due to exception raised, or some other reason -- segfault? abort?) might be interesting. (In reply to Conrad Meyer from comment #4) The stack might be useful to infer the exception type and to print it in case it was forgotten. I am reopening this PR in order to attract more comments. I see the potential usefulness of this, but I don't like the hacklike character of the proposed solution. |