Begin forwarded message: > From: Jon Shier <[email protected]> > Subject: Re: [swift-users] intercept fatalError() or other termination > messages from swift? > Date: June 26, 2017 at 12:30:50 PM PDT > To: David Baraff <[email protected]> > Cc: Joe Groff <[email protected]>, swift-users <[email protected]> > > If you export the crash from Xcode, do you see the string in the raw report?
No. > > > > Jon > >> On Jun 26, 2017, at 3:22 PM, David Baraff via swift-users >> <[email protected] <mailto:[email protected]>> wrote: >> >> To be very clear, i’m concerned about iOS not mac os x. I pulled up a crash >> report using xcode tools, and saw no mention of the string output by fatal >> error. If there is someway after the fact of, on an iPhone or iOS >> interogating the asl_log when you restart your program to glean the error >> message, i’m all ears. >> >> >>> On Jun 26, 2017, at 10:01 AM, Joe Groff <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On Jun 23, 2017, at 9:13 PM, David Baraff via swift-users >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> I realize this is slightly centric to iOS, but it irks me that both >>>> Apple’s crash report logs and popular platforms like PLCrashReporter can >>>> do the hard stuff like give you a stack trace, but are *completely* unable >>>> to display the error message from terminating a program via fatalError(), >>>> or the error message from, e.g. dying with a bad optional. >>>> >>>> Is there *any* to intercept the error messages that from fatalError() and >>>> similar like things in swift (bad optionals, invalid array accesses, >>>> assertions)? I would think that some sort of a “hook” into these standard >>>> error routines would be a good thing. >>>> >>>> In my case, if I could simply save that darn error string in a file, i >>>> could pick it up when the app next launches and report it along with the >>>> rest of the info like the stack/signal, etc. >>>> >>>> I’ve been looking through the code in stdlib/public/runtime/Errors.cpp but >>>> haven’t found anything promising that lets me jump in there. In my code, >>>> I’m likely to write things like >>>> guard let x = … else { >>>> fatalError(“Data type has payload <T> but is hooked to UI >>>> control with intrinsic type <U>”) >>>> } >>>> >>>> and having that exact string tells me precisely what’s going, far simpler >>>> than a stack trace. >>> >>> >>> Fatal error messages already get logged three ways: >>> >>> - Printed to the process's stderr; >>> - Logged to the system log using asl_log; >>> - Set as the crash reason for CrashReporter. >>> >>> The crash messages should thus already be in your crash reports somewhere. >>> See >>> https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L168 >>> >>> <https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L168> >>> and >>> https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L204 >>> >>> <https://github.com/jckarter/swift/blob/master/stdlib/public/runtime/Errors.cpp#L204> >>> for the relevant runtime source code. cc'ing Greg Parker who probably >>> knows better exactly where these messages end up. >>> >>> -Joe >> >> _______________________________________________ >> swift-users mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-users >
_______________________________________________ swift-users mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-users
