www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Exception isn't thrown as expected

reply Alexandr Druzhinin <drug2004 bk.ru> writes:
Hello
I have code like this:

class SomeClass {
ubyte[] data_;

...

     auto getObjectType() const {
     	if(data_ is null) {
     		writeln("throwing");
     		throw new Exception("Here the exception should be thrown!");
     	}
         KeyHeaderHelper value_header;
         value_header.ptr_ = cast(ubyte*) data_.ptr;
         return value_header.object_type;
     }
}

When data_ is null the application just prints "throwing" and hangs up 
without an exception throwing. I don't know how to handle this. May be I 
did something wrong? If so then what?
May 30 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
three questions come to mind:

1) what operating system and 32 bit or 64 bit?
2) what D compiler?
3) are you sure you didn't catch the exception somewhere up the 
chain and silence the message that way?
May 30 2013
parent reply Alexandr Druzhinin <drug2004 bk.ru> writes:
31.05.2013 8:59, Adam D. Ruppe пишет:

 three questions come to mind:

 1) what operating system and 32 bit or 64 bit?
 2) what D compiler?
 3) are you sure you didn't catch the exception somewhere up the chain
 and silence the message that way?


1) win7 64
2) dmd 32
3) I don't catch explicitly. To ensure it isn't catch some way 
implicitly I just throw Exception without condition and it is thrown as 
expected
auto getObjectType() const {
         throw new Exception("Here the exception should be thrown!"); // 
works as expected
         KeyHeaderHelper value_header;
         value_header.ptr_ = cast(ubyte*) data_.ptr;
         return value_header.object_type; // if data isn't null it hangs 
up here
     }

moreover, when I provide data_ always have some length, the application 
starts hangin at return operator. I've met something like this behaviour 
(I mean silent hanging up) earlier working with std.concurrency, but I 
found some workaround. Now I dont know what to do.
May 30 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 31 May 2013 10:26:49 +0700
schrieb Alexandr Druzhinin <drug2004 bk.ru>:


 31.05.2013 8:59, Adam D. Ruppe =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 three questions come to mind:

 1) what operating system and 32 bit or 64 bit?
 2) what D compiler?
 3) are you sure you didn't catch the exception somewhere up the chain
 and silence the message that way?


 1) win7 64
 2) dmd 32
 3) I don't catch explicitly. To ensure it isn't catch some way=20
 implicitly I just throw Exception without condition and it is thrown as=20
 expected
 auto getObjectType() const {
          throw new Exception("Here the exception should be thrown!"); //=


=20

 works as expected
          KeyHeaderHelper value_header;
          value_header.ptr_ =3D cast(ubyte*) data_.ptr;
          return value_header.object_type; // if data isn't null it hangs=


=20

 up here
      }
=20
 moreover, when I provide data_ always have some length, the application=20
 starts hangin at return operator. I've met something like this behaviour=


=20

 (I mean silent hanging up) earlier working with std.concurrency, but I=20
 found some workaround. Now I dont know what to do.


The code that you haven't shown reads:

  int main(string[] args) {
      SomeClass c;
      auto t =3D c.getObjectType();
      return 0;
  }

You have to fix that!

--=20
Marco
May 30 2013
parent reply Alexandr Druzhinin <drug2004 bk.ru> writes:
31.05.2013 10:49, Marco Leise пишет:

 The code that you haven't shown reads:

    int main(string[] args) {
        SomeClass c;
        auto t = c.getObjectType();
        return 0;
    }

 You have to fix that!


You mean I didn't initialize c? If even so, it should throw an 
exception, no hanging, I think. Nevertheless, a class instance is 
correct. I'll try to reduce code.
May 30 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 31 May 2013 10:59:09 +0700
schrieb Alexandr Druzhinin <drug2004 bk.ru>:


 You mean I didn't initialize c?


It was a wild guess, that you might come from C++ and write

  SomeClass c;

which would be an instance of that class in C++, but a null
reference in D. As you said you only get the hanging when you
compare the this.data_ field with null it could have made some
sense.


 If even so, it should throw an 
 exception, no hanging, I think. Nevertheless, a class instance is 
 correct. I'll try to reduce code.


Others may know for sure, but I think D only throws
NullPointerExceptions in  safe code and leaves it to the
operating system to stop your program in other cases. So on
Linux it would SEGFAULT and on Windows you probably get a
message box. But yeah... that still doesn't explain the
hanging :D

-- 
Marco
May 31 2013
prev sibling next sibling parent reply Alexandr Druzhinin <drug2004 bk.ru> writes:
31.05.2013 8:56, Alexandr Druzhinin пишет:

 Hello
 I have code like this:

 class SomeClass {
 ubyte[] data_;

 ...

      auto getObjectType() const {
          if(data_ is null) {
              writeln("throwing");
              throw new Exception("Here the exception should be thrown!");
          }
          KeyHeaderHelper value_header;
          value_header.ptr_ = cast(ubyte*) data_.ptr;
          return value_header.object_type;
      }
 }

 When data_ is null the application just prints "throwing" and hangs up
 without an exception throwing. I don't know how to handle this. May be I
 did something wrong? If so then what?


can't reduce code enough, but I found that after calling 
std.concurrency.spawn() template - exceptions stop throwing, but if I 
add little delay in beginning of spawned thread about 100 ms - it'd 
works again and exceptions would be thrown again... :(
Jun 02 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/02/2013 08:23 PM, Alexandr Druzhinin wrote:


 I found that after calling
 std.concurrency.spawn() template - exceptions stop throwing, but if I
 add little delay in beginning of spawned thread about 100 ms - it'd
 works again and exceptions would be thrown again... :(


Is the exception thrown by a child thread? If so, perhaps that is 
causing the child to terminate. Also, the parent cannot catch a child's 
exception automatically.

Ali
Jun 02 2013
parent reply Alexandr Druzhinin <drug2004 bk.ru> writes:
03.06.2013 12:26, Ali Çehreli пишет:

 On 06/02/2013 08:23 PM, Alexandr Druzhinin wrote:

  > I found that after calling
  > std.concurrency.spawn() template - exceptions stop throwing, but if I
  > add little delay in beginning of spawned thread about 100 ms - it'd
  > works again and exceptions would be thrown again... :(

 Is the exception thrown by a child thread? If so, perhaps that is
 causing the child to terminate. Also, the parent cannot catch a child's
 exception automatically.

 Ali


no, the main thread do it. But even if child thread throws an exception, 
should it print some diagnostic message to clear that it crashed or no? 
Because my app just hangs up and nothing more, no message, no 
complaints, nothing.
Jun 03 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, June 03, 2013 14:30:48 Alexandr Druzhinin wrote:

 03.06.2013 12:26, Ali =C3=87ehreli =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 On 06/02/2013 08:23 PM, Alexandr Druzhinin wrote:
  > I found that after calling
  > std.concurrency.spawn() template - exceptions stop throwing, but=




 if I

  > add little delay in beginning of spawned thread about 100 ms - i=




t'd

  > works again and exceptions would be thrown again... :(
=20
 Is the exception thrown by a child thread? If so, perhaps that is
 causing the child to terminate. Also, the parent cannot catch a chi=




ld's

 exception automatically.
=20
 Ali


=20
 no, the main thread do it. But even if child thread throws an excepti=


on,

 should it print some diagnostic message to clear that it crashed or n=


o?

 Because my app just hangs up and nothing more, no message, no
 complaints, nothing.


It would be simple enough to test, but I don't think that anything info=
rms you=20
of what happened to the child thread. If you try and send a message to =
it, I=20
think that you get an exception indicating the the thread terminated=20=

incorrectly, but I'm not sure. You'd have to test it to see exactly wha=
t it=20
does.

- Jonathan M Davis
Jun 03 2013
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/03/2013 12:30 AM, Alexandr Druzhinin wrote:


 if child thread throws an exception,
 should it print some diagnostic message to clear that it crashed or no?


No, the parent does not know about such a termination. These are the 
following options that I know of:

1) The exceptions can be caught by the child and sent to the owner 
explicitly as a special message that both understand.

Or the exception can directly be passed as a message:

2)
     try {
         // ...

     } catch (shared(Exception) exc) {
         owner.send(exc);
     },

The owner receives that message just like a message:

     receive(
         // ...

         (shared(Exception) exc) {
             throw exc;
         });

The code above re-throws the child's exception in the owner's context 
but it could do anything else as well.

There are also the following exceptions that are related to std.concurrency:

* MessageMismatch
* OwnerTerminated
* LinkTerminated
* MailboxFull
* PriorityMessageException

I have some examples here:

   http://ddili.org/ders/d.en/concurrency.html

Ali
Jun 03 2013
prev sibling parent reply Alexandr Druzhinin <drug2004 bk.ru> writes:
31.05.2013 8:56, Alexandr Druzhinin пишет:

 Hello
 I have code like this:

 class SomeClass {
 ubyte[] data_;

 ...

      auto getObjectType() const {
          if(data_ is null) {
              writeln("throwing");
              throw new Exception("Here the exception should be thrown!");
          }
          KeyHeaderHelper value_header;
          value_header.ptr_ = cast(ubyte*) data_.ptr;
          return value_header.object_type;
      }
 }

 When data_ is null the application just prints "throwing" and hangs up
 without an exception throwing. I don't know how to handle this. May be I
 did something wrong? If so then what?


Rephrase my question - I have a function getObjectType, that throws an 
exception. Unittest is ok. But in more complex use case, this function 
doesn't throw exception and just hangs up. If I brace the function call 
by try/catch then an exception is throw again. But I guess exception 
have to be thrown in any case.
Jun 04 2013
parent Alexandr Druzhinin <drug2004 bk.ru> writes:
04.06.2013 19:18, Alexandr Druzhinin пишет:

 31.05.2013 8:56, Alexandr Druzhinin пишет:

 Hello
 I have code like this:

 class SomeClass {
 ubyte[] data_;

 ...

      auto getObjectType() const {
          if(data_ is null) {
              writeln("throwing");
              throw new Exception("Here the exception should be thrown!");
          }
          KeyHeaderHelper value_header;
          value_header.ptr_ = cast(ubyte*) data_.ptr;
          return value_header.object_type;
      }
 }

 When data_ is null the application just prints "throwing" and hangs up
 without an exception throwing. I don't know how to handle this. May be I
 did something wrong? If so then what?


 Rephrase my question - I have a function getObjectType, that throws an
 exception. Unittest is ok. But in more complex use case, this function
 doesn't throw exception and just hangs up. If I brace the function call
 by try/catch then an exception is throw again. But I guess exception
 have to be thrown in any case.


Oh, no.. If I do

...
try {
	auto foo =  some_class_instance.getObjectType();
}
catch(Throwable t) {
	writeln(t.msg); // print exception, no hanging
	throw t;	// hangs again
}
...
all happens in the main thread.
Jun 04 2013