Begin forwarded message: > From: Jon Shier <j...@jonshier.com> > 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 <davidbar...@gmail.com> > Cc: Joe Groff <jgr...@apple.com>, swift-users <swift-users@swift.org> > > 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 >> <swift-users@swift.org <mailto:swift-users@swift.org>> 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 <jgr...@apple.com >>> <mailto:jgr...@apple.com>> wrote: >>> >>> >>>> On Jun 23, 2017, at 9:13 PM, David Baraff via swift-users >>>> <swift-users@swift.org <mailto:swift-users@swift.org>> 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 >> swift-users@swift.org <mailto:swift-users@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-users >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
