www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Exceptions

reply Steve Teale <steve.teale britseyeview.com> writes:
If I have a program like:

import std.stdio;
void main()
{
    try
    {
         char* p = cast(char*) 1234;
         *p = '?';
    }
    catch (Exception x)     // same story with Exception or Error
    {
        writefln("Caught Exception");
    }
}

If I build and run in in Linux, with either DMD 1.055 or the current GDC, the
program quits with a Segmentation fault message. Under Windows (and I am
running an old D2 there), it says:

object.Error: Access Violation

Which looks like a message from D. If I write a D Linux program that just
throws an exception, then it says:

Error: My exception message

Which is clearly a message from D.

So it seems there is a safety net in Windows, but not in Linux. Is this how it
is supposed to be?
Jan 26 2010
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Steve Teale wrote:
 ...
 
 So it seems there is a safety net in Windows, but not in Linux. Is this how it
is supposed to be?

Under Windows, access violations cause the OS to throw an exception. Since D uses the same EH mechanism as the OS, this integrates nicely. Under linux, SIGSEGV is a signal, and you can't safely throw exceptions from signal handlers, so D just aborts. As far as I understand it, it's a limitation of the way linux is designed.
Jan 26 2010
next sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
Daniel Keep Wrote:

 
 
 Steve Teale wrote:
 ...
 
 So it seems there is a safety net in Windows, but not in Linux. Is this how it
is supposed to be?

Under Windows, access violations cause the OS to throw an exception. Since D uses the same EH mechanism as the OS, this integrates nicely. Under linux, SIGSEGV is a signal, and you can't safely throw exceptions from signal handlers, so D just aborts. As far as I understand it, it's a limitation of the way linux is designed.

Thanks Daniel, now I've had time to get something to eat and a couple of beers, that makes complete sense. So basically, under Linux, there's not much your program can do to protect itself against errors in library code, right? I hate signals, particularly when doing multi-threaded stuff.
Jan 26 2010
parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Steve Teale wrote:
 Daniel Keep Wrote:
 
 Steve Teale wrote:
 ...

 So it seems there is a safety net in Windows, but not in Linux. Is this how it
is supposed to be?

Since D uses the same EH mechanism as the OS, this integrates nicely. Under linux, SIGSEGV is a signal, and you can't safely throw exceptions from signal handlers, so D just aborts. As far as I understand it, it's a limitation of the way linux is designed.

Thanks Daniel, now I've had time to get something to eat and a couple of beers, that makes complete sense. So basically, under Linux, there's not much your program can do to protect itself against errors in library code, right?

Well, you can intercept signals, but it requires you to get down and dirty with some C-style programming: http://agenda.ictp.trieste.it/agenda_links/smr1335/rt2001/node8.html The relevant modules are: D1: std.c.linux.linux D2: core.sys.posix.signal -Lars
Jan 26 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:hjn49d$2kfe$1 digitalmars.com...
 Under linux, SIGSEGV is a signal, and you can't safely throw exceptions
 from signal handlers, so D just aborts.

Just out of curiosity, is that a limitation that comes from the basic concept of signals, or just a detail of how the OS just happens to do signals?
Jan 26 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Tue, 26 Jan 2010 15:07:50 -0500, Nick Sabalausky <a a.a> wrote:
 
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message
 news:hjn49d$2kfe$1 digitalmars.com...
 Under linux, SIGSEGV is a signal, and you can't safely throw exceptions
 from signal handlers, so D just aborts.

Just out of curiosity, is that a limitation that comes from the basic concept of signals, or just a detail of how the OS just happens to do signals?

I think it's because a signal handler is entered at any point in the call stack. This means that to unwind the stack, you need to unwind possibly C functions and (I think) even system calls. The safest thing to do in a signal handler is to set a flag indicating a signal was recieved, and then asynchronously process it. Given that you could be in C or C++ land where exceptions either don't exist or are different, you face a very difficult task to unwind the stack correctly. -Steve

Yah it's the asynchrony of signals. Exceptions are synchronous, which makes them a great deal simpler than they otherwise could. Andrei
Jan 26 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 26 Jan 2010 15:07:50 -0500, Nick Sabalausky <a a.a> wrote:

 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message
 news:hjn49d$2kfe$1 digitalmars.com...
 Under linux, SIGSEGV is a signal, and you can't safely throw exceptions
 from signal handlers, so D just aborts.

Just out of curiosity, is that a limitation that comes from the basic concept of signals, or just a detail of how the OS just happens to do signals?

I think it's because a signal handler is entered at any point in the call stack. This means that to unwind the stack, you need to unwind possibly C functions and (I think) even system calls. The safest thing to do in a signal handler is to set a flag indicating a signal was recieved, and then asynchronously process it. Given that you could be in C or C++ land where exceptions either don't exist or are different, you face a very difficult task to unwind the stack correctly. -Steve
Jan 26 2010
prev sibling parent BCS <none anon.com> writes:
Hello Daniel,

 
 Under linux, SIGSEGV is a signal, and you can't safely throw
 exceptions from signal handlers, so D just aborts.
 

While you can't *safely* throw, you can often (but not always) get away with it, and in many cases trying to will result in nothing worse than just letting things crash. -- <IXOYE><
Jan 26 2010
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tue, Jan 26, 2010 at 11:07:11AM -0500, Steve Teale wrote:
 So it seems there is a safety net in Windows, but not in Linux. Is this how it
is supposed to be?

Yes - it has to do with the difference in how the two operating systems alert the program about hardware signaled errors. -- Adam D. Ruppe http://arsdnet.net
Jan 26 2010