(posted here because so few people read the druntime list)

I've been working on allowing core dumps to be created when an unhandled exception is thrown in a D app.  To avoid some weirdness that arises when an exception is thrown beyond the scope of (C) main() I'm calling abort() after terminating everything possible and reporting the exception.  What I'm wondering is whether this is an acceptable way to terminate a D app in this situation or if I should do something else.  I was looking at the Win32 docs for abort() and they're a bit weird:

    By default, the abort routine prints the message:

    "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information."

    It then calls raise(SIGABRT).

Even on OSX I see an "Abort trap" message in the console when I exit an app in this way.  I'm inclined to think that this isn't acceptable and that I should just try and sort out the weirdness that results from throwing an object outside of main(), but I thought I'd ask here for suggestions.  As an alternative I could call asm HLT, but this may bypass too much C-level runtime stuff.  Thoughts?

Unhandled exceptions should print the error message associated with the exception. This is so that, for example, you can write a file copy program without paying any attention to error messages. If an error happens, the program will print the right error message.

Getting a core dump instead would be most unattractive.

Sean Kelly wrote:
> (posted here because so few people read the druntime list)
>
> I've been working on allowing core dumps to be created when an unhandled exception is thrown in a D app.  To avoid some weirdness that arises when an exception is thrown beyond the scope of (C) main() I'm calling abort() after terminating everything possible and reporting the exception.  What I'm wondering is whether this is an acceptable way to terminate a D app in this situation or if I should do something else.  I was looking at the Win32 docs for abort() and they're a bit weird:
>
>     By default, the abort routine prints the message:
>
>     "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information."
>
>     It then calls raise(SIGABRT).
>
> Even on OSX I see an "Abort trap" message in the console when I exit an app in this way.  I'm inclined to think that this isn't acceptable and that I should just try and sort out the weirdness that results from throwing an object outside of main(), but I thought I'd ask here for suggestions.  As an alternative I could call asm HLT, but this may bypass too much C-level runtime stuff.  Thoughts?
>
> 

Le 2010-07-29 ? 19:50, Sean Kelly a ?crit :

> Even on OSX I see an "Abort trap" message in the console when I exit an app in this way.  I'm inclined to think that this isn't acceptable and that I should just try and sort out the weirdness that results from throwing an object outside of main(), but I thought I'd ask here for suggestions.  As an alternative I could call asm HLT, but this may bypass too much C-level runtime stuff.  Thoughts?

To put things in perspective: on OSX, if I throw an Objective-C exception and it is unhandled, I get this output:

2010-07-29 20:08:50.818 Nib Preview Helper[1875:a0f] *** Terminating app due to uncaught exception 'hello', reason: 'test'
*** Call stack at first throw:
(
	0   CoreFoundation                      0x00007fff810cecc4 __exceptionPreprocess + 180
	1   libobjc.A.dylib                     0x00007fff80d0d0f3 objc_exception_throw + 45
	2   TestApplication                     0x00000001000012c2 main + 162
	3   TestApplication                     0x00000001000011f4 start + 52
	4   ???                                 0x0000000000000001 0x0 + 1
)
terminate called after throwing an instance of 'NSException'
Program received signal:  ?SIGABRT?.
sharedlibrary apply-load-rules all
(gdb) backtrace
#0  0x00007fff86e363d6 in __kill ()
#1  0x00007fff86ed6972 in abort ()
#2  0x00007fff83e315d2 in __gnu_cxx::__verbose_terminate_handler ()
#3  0x00007fff80d10d29 in _objc_terminate ()
#4  0x00007fff83e2fae1 in __cxxabiv1::__terminate ()
#5  0x00007fff83e2fb16 in std::terminate ()
#6  0x00007fff83e2fbfc in __cxa_throw ()
#7  0x00007fff80d0d192 in objc_exception_throw ()
#8  0x00000001000012c2 in main (argc=1, argv=0x7fff5fbff7c0) at main.m:28
(gdb)

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

The error is still printed, I'm trying to create a core dump also.

Sent from my iPhone

On Jul 29, 2010, at 5:07 PM, Walter Bright <walter at digitalmars.com> wrote:

> Unhandled exceptions should print the error message associated with the exception. This is so that, for example, you can write a file copy program without paying any attention to error messages. If an error happens, the program will print the right error message.
> 
> Getting a core dump instead would be most unattractive.
> 
> Sean Kelly wrote:
>> (posted here because so few people read the druntime list)
>> 
>> I've been working on allowing core dumps to be created when an unhandled exception is thrown in a D app.  To avoid some weirdness that arises when an exception is thrown beyond the scope of (C) main() I'm calling abort() after terminating everything possible and reporting the exception.  What I'm wondering is whether this is an acceptable way to terminate a D app in this situation or if I should do something else.  I was looking at the Win32 docs for abort() and they're a bit weird:
>> 
>>    By default, the abort routine prints the message:
>> 
>>    "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information."
>> 
>>    It then calls raise(SIGABRT).
>> 
>> Even on OSX I see an "Abort trap" message in the console when I exit an app in this way.  I'm inclined to think that this isn't acceptable and that I should just try and sort out the weirdness that results from throwing an object outside of main(), but I thought I'd ask here for suggestions.  As an alternative I could call asm HLT, but this may bypass too much C-level runtime stuff.  Thoughts?
>> 
>> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

I suggest you call raise(SIGABRT) directly so you don't see the weird messages printed by the runtimes.

Andrei

Sean Kelly wrote:
> The error is still printed, I'm trying to create a core dump also.
> 
> Sent from my iPhone
> 
> On Jul 29, 2010, at 5:07 PM, Walter Bright <walter at digitalmars.com> wrote:
> 
>> Unhandled exceptions should print the error message associated with the exception. This is so that, for example, you can write a file copy program without paying any attention to error messages. If an error happens, the program will print the right error message.
>>
>> Getting a core dump instead would be most unattractive.
>>
>> Sean Kelly wrote:
>>> (posted here because so few people read the druntime list)
>>>
>>> I've been working on allowing core dumps to be created when an unhandled exception is thrown in a D app.  To avoid some weirdness that arises when an exception is thrown beyond the scope of (C) main() I'm calling abort() after terminating everything possible and reporting the exception.  What I'm wondering is whether this is an acceptable way to terminate a D app in this situation or if I should do something else.  I was looking at the Win32 docs for abort() and they're a bit weird:
>>>
>>>    By default, the abort routine prints the message:
>>>
>>>    "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information."
>>>
>>>    It then calls raise(SIGABRT).
>>>
>>> Even on OSX I see an "Abort trap" message in the console when I exit an app in this way.  I'm inclined to think that this isn't acceptable and that I should just try and sort out the weirdness that results from throwing an object outside of main(), but I thought I'd ask here for suggestions.  As an alternative I could call asm HLT, but this may bypass too much C-level runtime stuff.  Thoughts?
>>>
>>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Huh, so the ObjC behavior is to print the exception and abort() too.  Looks like good justification for doing it in D as well then.

Sent from my iPhone

On Jul 29, 2010, at 5:14 PM, Michel Fortin <michel.fortin at michelf.com> wrote:

> Le 2010-07-29 ? 19:50, Sean Kelly a ?crit :
> 
>> Even on OSX I see an "Abort trap" message in the console when I exit an app in this way.  I'm inclined to think that this isn't acceptable and that I should just try and sort out the weirdness that results from throwing an object outside of main(), but I thought I'd ask here for suggestions.  As an alternative I could call asm HLT, but this may bypass too much C-level runtime stuff.  Thoughts?
> 
> To put things in perspective: on OSX, if I throw an Objective-C exception and it is unhandled, I get this output:
> 
> 2010-07-29 20:08:50.818 Nib Preview Helper[1875:a0f] *** Terminating app due to uncaught exception 'hello', reason: 'test'
> *** Call stack at first throw:
> (
>    0   CoreFoundation                      0x00007fff810cecc4 __exceptionPreprocess + 180
>    1   libobjc.A.dylib                     0x00007fff80d0d0f3 objc_exception_throw + 45
>    2   TestApplication                     0x00000001000012c2 main + 162
>    3   TestApplication                     0x00000001000011f4 start + 52
>    4   ???                                 0x0000000000000001 0x0 + 1
> )
> terminate called after throwing an instance of 'NSException'
> Program received signal:  ?SIGABRT?.
> sharedlibrary apply-load-rules all
> (gdb) backtrace
> #0  0x00007fff86e363d6 in __kill ()
> #1  0x00007fff86ed6972 in abort ()
> #2  0x00007fff83e315d2 in __gnu_cxx::__verbose_terminate_handler ()
> #3  0x00007fff80d10d29 in _objc_terminate ()
> #4  0x00007fff83e2fae1 in __cxxabiv1::__terminate ()
> #5  0x00007fff83e2fb16 in std::terminate ()
> #6  0x00007fff83e2fbfc in __cxa_throw ()
> #7  0x00007fff80d0d192 in objc_exception_throw ()
> #8  0x00000001000012c2 in main (argc=1, argv=0x7fff5fbff7c0) at main.m:28
> (gdb)
> 
> -- 
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
> 
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Sounds good.

Sent from my iPhone

On Jul 29, 2010, at 6:47 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:

> I suggest you call raise(SIGABRT) directly so you don't see the weird messages printed by the runtimes.
> 
> Andrei
> 
> Sean Kelly wrote:
>> The error is still printed, I'm trying to create a core dump also. Sent from my iPhone On Jul 29, 2010, at 5:07 PM, Walter Bright <walter at digitalmars.com> wrote:
>>> Unhandled exceptions should print the error message associated with the exception. This is so that, for example, you can write a file copy program without paying any attention to error messages. If an error happens, the program will print the right error message.
>>> 
>>> Getting a core dump instead would be most unattractive.
>>> 
>>> Sean Kelly wrote:
>>>> (posted here because so few people read the druntime list)
>>>> 
>>>> I've been working on allowing core dumps to be created when an unhandled exception is thrown in a D app.  To avoid some weirdness that arises when an exception is thrown beyond the scope of (C) main() I'm calling abort() after terminating everything possible and reporting the exception.  What I'm wondering is whether this is an acceptable way to terminate a D app in this situation or if I should do something else.  I was looking at the Win32 docs for abort() and they're a bit weird:
>>>> 
>>>>   By default, the abort routine prints the message:
>>>> 
>>>>   "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information."
>>>> 
>>>>   It then calls raise(SIGABRT).
>>>> 
>>>> Even on OSX I see an "Abort trap" message in the console when I exit an app in this way.  I'm inclined to think that this isn't acceptable and that I should just try and sort out the weirdness that results from throwing an object outside of main(), but I thought I'd ask here for suggestions.  As an alternative I could call asm HLT, but this may bypass too much C-level runtime stuff.  Thoughts?
>>>> 
>>>> 
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Asside from the stack trace (which I'm guessing comes from _objc_terminate() in the stack below), that's what a c++ core file from g++ would look like from an assert or uncaught exception.  They both end up in abort.

On Thu, 29 Jul 2010, Sean Kelly wrote:

> Date: Thu, 29 Jul 2010 18:52:47 -0700
> From: Sean Kelly <sean at invisibleduck.org>
> Reply-To: Discuss the phobos library for D <phobos at puremagic.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Cc: Discuss the phobos library for D <phobos at puremagic.com>
> Subject: Re: [phobos] Calling abort() on unhandled exception
> 
> Huh, so the ObjC behavior is to print the exception and abort() too.  Looks like good justification for doing it in D as well then.
> 
> Sent from my iPhone
> 
> On Jul 29, 2010, at 5:14 PM, Michel Fortin <michel.fortin at michelf.com> wrote:
> 
> > Le 2010-07-29 ? 19:50, Sean Kelly a ?crit :
> > 
> >> Even on OSX I see an "Abort trap" message in the console when I exit an app in this way.  I'm inclined to think that this isn't acceptable and that I should just try and sort out the weirdness that results from throwing an object outside of main(), but I thought I'd ask here for suggestions.  As an alternative I could call asm HLT, but this may bypass too much C-level runtime stuff.  Thoughts?
> > 
> > To put things in perspective: on OSX, if I throw an Objective-C exception and it is unhandled, I get this output:
> > 
> > 2010-07-29 20:08:50.818 Nib Preview Helper[1875:a0f] *** Terminating app due to uncaught exception 'hello', reason: 'test'
> > *** Call stack at first throw:
> > (
> >    0   CoreFoundation                      0x00007fff810cecc4 __exceptionPreprocess + 180
> >    1   libobjc.A.dylib                     0x00007fff80d0d0f3 objc_exception_throw + 45
> >    2   TestApplication                     0x00000001000012c2 main + 162
> >    3   TestApplication                     0x00000001000011f4 start + 52
> >    4   ???                                 0x0000000000000001 0x0 + 1
> > )
> > terminate called after throwing an instance of 'NSException'
> > Program received signal:  ?SIGABRT?.
> > sharedlibrary apply-load-rules all
> > (gdb) backtrace
> > #0  0x00007fff86e363d6 in __kill ()
> > #1  0x00007fff86ed6972 in abort ()
> > #2  0x00007fff83e315d2 in __gnu_cxx::__verbose_terminate_handler ()
> > #3  0x00007fff80d10d29 in _objc_terminate ()
> > #4  0x00007fff83e2fae1 in __cxxabiv1::__terminate ()
> > #5  0x00007fff83e2fb16 in std::terminate ()
> > #6  0x00007fff83e2fbfc in __cxa_throw ()
> > #7  0x00007fff80d0d192 in objc_exception_throw ()
> > #8  0x00000001000012c2 in main (argc=1, argv=0x7fff5fbff7c0) at main.m:28
> > (gdb)
> > 
> > -- 
> > Michel Fortin
> > michel.fortin at michelf.com
> > http://michelf.com/
> > 
> > 
> > 
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Le 2010-07-29 ? 21:52, Sean Kelly a ?crit :

> Huh, so the ObjC behavior is to print the exception and abort() too.

Mostly. Actually, it seems it calls the C++ runtime's std::terminate, which in turns call a user-settable handler function which is abort() if you haven't changed it.


> Looks like good justification for doing it in D as well then.


I think it's the right thing to do, for OSX at least.

Perhaps it could be useful if the programmer could substitute his own handler function (similar to what you can do with std::set_terminate in C++) if he wants to do something special (such as a core dump).

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

I think we misunderstand each other. A file copy program that fails due to, say, the disk being full, should not produce a core dump. It should produce an error message like:

   error: disk full

An uncaught exception is NOT an invalid or crashed program in D.

Sean Kelly wrote:
> The error is still printed, I'm trying to create a core dump also.
>
> Sent from my iPhone
>
> On Jul 29, 2010, at 5:07 PM, Walter Bright <walter at digitalmars.com> wrote:
>
> 
>> Unhandled exceptions should print the error message associated with the exception. This is so that, for example, you can write a file copy program without paying any attention to error messages. If an error happens, the program will print the right error message.
>>
>> Getting a core dump instead would be most unattractive.
>>
>> Sean Kelly wrote:
>> 
>>> (posted here because so few people read the druntime list)
>>>
>>> I've been working on allowing core dumps to be created when an unhandled exception is thrown in a D app.  To avoid some weirdness that arises when an exception is thrown beyond the scope of (C) main() I'm calling abort() after terminating everything possible and reporting the exception.  What I'm wondering is whether this is an acceptable way to terminate a D app in this situation or if I should do something else.  I was looking at the Win32 docs for abort() and they're a bit weird:
>>>
>>>    By default, the abort routine prints the message:
>>>
>>>    "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information."
>>>
>>>    It then calls raise(SIGABRT).
>>>
>>> Even on OSX I see an "Abort trap" message in the console when I exit an app in this way.  I'm inclined to think that this isn't acceptable and that I should just try and sort out the weirdness that results from throwing an object outside of main(), but I thought I'd ask here for suggestions.  As an alternative I could call asm HLT, but this may bypass too much C-level runtime stuff.  Thoughts?
>>>
>>> 
>>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>