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 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 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=


 or Exception type implementating base exception mechanics and/or an =20
 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? =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
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 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 next sibling parent "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
prev sibling next 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).

Object.toString() Stewart.
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...

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 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...

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
prev sibling next sibling parent 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
prev sibling 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