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