www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - exception types & objects

reply spir <denis.spir gmail.com> writes:
Hello,

The reference states:

ThrowStatement:
	throw Expression ;
Expression is evaluated and must be an Object reference. The Object referen=
ce is thrown as an exception.
	throw new Exception("message");

The example uses an Excpetion type, but the somewhat comment contradicts it=
. Can one really use any kind of object as exception? How does D then handl=
e it? I was expecting (from exp with other language) there to be a root Err=
or or Exception type implementating base exception mechanics and/or an impo=
sed interface to comply with (esp a kind of string method returning what te=
xt to write out when the exception is not caught).
How does this work, and how to use it concretely?

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Oct 19 2010
next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
spir <denis.spir gmail.com> wrote:


 Hello,

 The reference states:

 ThrowStatement:
 	throw Expression ;
 Expression is evaluated and must be an Object reference. The Object  
 reference is thrown as an exception.
 	throw new Exception("message");

 The example uses an Excpetion type, but the somewhat comment contradicts  
 it. Can one really use any kind of object as exception?


Absolutely. It is however heavily discouraged.



 How does D then handle it?


The way it does any other exception. You may catch it using
catch(Object o).



 I was expecting (from exp with other language) there to be a root Error  
 or Exception type implementating base exception mechanics and/or an  
 imposed interface to comply with (esp a kind of string method returning  
 what text to write out when the exception is not caught).
 How does this work, and how to use it concretely?


There is a base class Exception and Error, as well as the base interface
Throwable, which the aforementioned implement. Using this is more of a
convention than absolute necessity, but it is used all over Phobos and
druntime, and it is heavily discouraged not to use those as bases.

On a sidenote, one should usually only catch Exceptions, not Errors, as
the latter is supposed to be used for non-recoverable errors.

-- 
Simen
Oct 19 2010
parent reply spir <denis.spir gmail.com> writes:
On Tue, 19 Oct 2010 14:52:20 +0200
"Simen kjaeraas" <simen.kjaras gmail.com> wrote:


 I was expecting (from exp with other language) there to be a root Error=




 =20

 or Exception type implementating base exception mechanics and/or an =20
 imposed interface to comply with (esp a kind of string method returning=




 =20

 what text to write out when the exception is not caught).
 How does this work, and how to use it concretely? =20


=20
 There is a base class Exception and Error, as well as the base interface
 Throwable, which the aforementioned implement. Using this is more of a
 convention than absolute necessity, but it is used all over Phobos and
 druntime, and it is heavily discouraged not to use those as bases.


Good. Is this documented somewhere (have searched language and library refe=
rences before asking: found some documents on peculiar aspects, but none de=
scribing the mechanism and how to use).


 On a sidenote, one should usually only catch Exceptions, not Errors, as
 the latter is supposed to be used for non-recoverable errors.


Very well, this matches my point of view.

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Oct 19 2010
parent Lutger <lutger.blijdestijn gmail.com> writes:
spir wrote:


 On Tue, 19 Oct 2010 14:52:20 +0200
 "Simen kjaeraas" <simen.kjaras gmail.com> wrote:
 

 I was expecting (from exp with other language) there to be a root
 Error or Exception type implementating base exception mechanics and/or
 an imposed interface to comply with (esp a kind of string method
 returning what text to write out when the exception is not caught).
 How does this work, and how to use it concretely?


 
 There is a base class Exception and Error, as well as the base interface
 Throwable, which the aforementioned implement. Using this is more of a
 convention than absolute necessity, but it is used all over Phobos and
 druntime, and it is heavily discouraged not to use those as bases.


 
 Good. Is this documented somewhere (have searched language and library
 references before asking: found some documents on peculiar aspects, but
 none describing the mechanism and how to use).


Unfortunately the relevant docs here seem to be a bit out of date.

look up nothrow:
http://www.digitalmars.com/d/2.0/function.html

this is out of date wrt the throwable hierarchy:
http://www.digitalmars.com/d/2.0/errors.html

contains related info, recommended:
http://www.digitalmars.com/d/2.0/exception-safe.html

If you want more details you could look up the header files of druntime 
distributed with the dmd package, specifically:

src/druntime/import/object.di: contains the Throwable, Error and Exception 
interfaces

src/druntime/import/core/exception.di: contains a few derived Exceptions
Oct 20 2010
prev sibling next sibling parent Kagamin <spam here.lot> writes:
spir Wrote:


 I was expecting (from exp with other language) there to be a root Error or
Exception type implementating base exception mechanics and/or an imposed
interface to comply with (esp a kind of string method returning what text to
write out when the exception is not caught).


Exception mechanics consists of taking an object pointer, putting it into
exception record, unwinding stack, catch takes the pointer, tests its runtime
type against what you specified in catch statement and gives the pointer to
user code. In fact, toString method is inherited from Object.
Oct 19 2010
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
spir Wrote:


 The example uses an Excpetion type, but the somewhat comment contradicts it.
Can one really use any kind of object as exception?


ps it's fun to throw strings in javascript, try it.
:3
Oct 19 2010
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 19 Oct 2010 22:54:33 +0400, Kagamin <spam here.lot> wrote:


 spir Wrote:


 The example uses an Excpetion type, but the somewhat comment  
 contradicts it. Can one really use any kind of object as exception?


 ps it's fun to throw strings in javascript, try it.
 :3


I've been throwing const char* in C++:

try {
	throw "not implemented";
} catch (const char* message) {
	printf("Exception: %s\n", message);
}
Oct 19 2010
parent div0 <div0 sourceforge.net> writes:
On 19/10/2010 20:03, Denis Koroskin wrote:

 On Tue, 19 Oct 2010 22:54:33 +0400, Kagamin <spam here.lot> wrote:


 spir Wrote:


 The example uses an Excpetion type, but the somewhat comment
 contradicts it. Can one really use any kind of object as exception?


 ps it's fun to throw strings in javascript, try it.
 :3


 I've been throwing const char* in C++:

 try {
 throw "not implemented";
 } catch (const char* message) {
 printf("Exception: %s\n", message);
 }


You evil man.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
Oct 19 2010
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 19/10/2010 13:13, spir wrote:
<snip>

 The example uses an Excpetion type, but the somewhat comment
 contradicts it. Can one really use any kind of object as exception?


Yes.


 How does D then handle it?


The mechanism is class-agnostic.  The only thing it relies on is that 
it's an object of some class type.


 I was expecting (from exp with other
 language) there to be a root Error or Exception type implementating
 base exception mechanics and/or an imposed interface to comply with


Imposed interface to do what with the exception?

OK, so I can think of one example it would be nice to have: stack 
traces.  This could be implemented in Exception, I suppose.  But still, 
restricting throw to this class would be a puristic rather than 
practical step forward.


 (esp a kind of string method returning what text to write out when
 the exception is not caught).


<snip>

Object.toString()

Stewart.
Oct 19 2010
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, October 19, 2010 12:36:23 Stewart Gordon wrote:

 On 19/10/2010 13:13, spir wrote:
 <snip>
 

 The example uses an Excpetion type, but the somewhat comment
 contradicts it. Can one really use any kind of object as exception?


 
 Yes.
 

 How does D then handle it?


 
 The mechanism is class-agnostic.  The only thing it relies on is that
 it's an object of some class type.
 

 I was expecting (from exp with other
 language) there to be a root Error or Exception type implementating
 base exception mechanics and/or an imposed interface to comply with


 
 Imposed interface to do what with the exception?
 
 OK, so I can think of one example it would be nice to have: stack
 traces.  This could be implemented in Exception, I suppose.  But still,
 restricting throw to this class would be a puristic rather than
 practical step forward.


Perhaps, but there is no real benefit in throwing anything other than an 
Exception (or Error upon occasion) and if we allow you to throw anything than 
catch(Exception e) won't catch them all. It also would pretty much violate 
nothrow since nothrow guarantees that no Exceptions are thrown from that 
function, and if you can throw any old object anyway...

I'd never heard of being able to throw anything which wasn't Throwable in D 
before reading this thread, and I'm appalled that it's possible. I'm very 
tempted to create  an enhancement request requesting that it be made 
_im_possible. I'm aware of no value in it. It's poor practice, can create 
confusion, and opens a whole in the language as far as nothrow goes

- Jonathan M Davis
Oct 19 2010
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 19/10/2010 23:23, Jonathan M Davis wrote:
<snip>

 Perhaps, but there is no real benefit in throwing anything other than
 an Exception (or Error upon occasion) and if we allow you to throw
 anything than catch(Exception e) won't catch them all. It also would
 pretty much violate nothrow since nothrow guarantees that no
 Exceptions are thrown from that function, and if you can throw any
 old object anyway...


<snip>

Indeed, "Nothrow functions do not throw any exceptions derived from 
class Exception" - seems odd to me.

I think I've had two uses in my time for throwing something that isn't 
an Exception:
- in a previous version of SDWF, to handle an awkward corner case in the 
Windows dialog API, though I later found a better way of dealing with it
- in the runtime for an Unlambda to D compiler, to serve as the 
continuation object, though that could just as well be changed

I hadn't realised until now that D2 had changed to have a Throwable 
class and Error and Exception classes derived therefrom.  It seems the 
intention was to prevent a nothrow function throwing anything other than 
an Error, but it wasn't quite said right.  So any solution should 
probably prevent circumvention by creating a whole new subclass of 
Throwable.  (By a quick look through the Java API docs, checked 
exception classes are defined as Throwable minus the RuntimeException 
and Error subclasses.)

Stewart.
Oct 21 2010
parent reply Don <nospam nospam.com> writes:
Stewart Gordon wrote:

 On 19/10/2010 23:23, Jonathan M Davis wrote:
 <snip>

 Perhaps, but there is no real benefit in throwing anything other than
 an Exception (or Error upon occasion) and if we allow you to throw
 anything than catch(Exception e) won't catch them all. It also would
 pretty much violate nothrow since nothrow guarantees that no
 Exceptions are thrown from that function, and if you can throw any
 old object anyway...


 <snip>
 
 Indeed, "Nothrow functions do not throw any exceptions derived from 
 class Exception" - seems odd to me.
 
 I think I've had two uses in my time for throwing something that isn't 
 an Exception:
 - in a previous version of SDWF, to handle an awkward corner case in the 
 Windows dialog API, though I later found a better way of dealing with it
 - in the runtime for an Unlambda to D compiler, to serve as the 
 continuation object, though that could just as well be changed
 
 I hadn't realised until now that D2 had changed to have a Throwable 
 class and Error and Exception classes derived therefrom.  It seems the 
 intention was to prevent a nothrow function throwing anything other than 
 an Error, but it wasn't quite said right.  So any solution should 
 probably prevent circumvention by creating a whole new subclass of 
 Throwable.  (By a quick look through the Java API docs, checked 
 exception classes are defined as Throwable minus the RuntimeException 
 and Error subclasses.)
 
 Stewart.


nothrow actually prevents you from throwing anything. A nothrow function 
may still perform operations which may throw a compiler-generated Error.
(eg, AssertError, OutOfMemoryError).
It's only a spec change which is required.
Oct 30 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 31 Oct 2010 02:51:53 -0400, Don <nospam nospam.com> wrote:


 nothrow actually prevents you from throwing anything. A nothrow function  
 may still perform operations which may throw a compiler-generated Error.
 (eg, AssertError, OutOfMemoryError).
 It's only a spec change which is required.


I think you meant to say runtime-generated errors?  If it's just a spec  
change, then why is the compiler failing to compile the code?

-Steve
Nov 02 2010