[swift-users] intercept fatalError() or other termination messages from swift?

[David Baraff]

Begin forwarded message:

> From: Jon Shier <jon at 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 <davidbaraff at gmail.com>
> Cc: Joe Groff <jgroff at apple.com>, swift-users <swift-users at 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 at swift.org <mailto:swift-users at 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 <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>> 
>>> 
>>>> On Jun 23, 2017, at 9:13 PM, David Baraff via swift-users <swift-users at swift.org <mailto:swift-users at 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 at swift.org <mailto:swift-users at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170626/179acdc7/attachment.html>