On Friday, 8 March 2013 at 18:56:38 UTC, Andrej Mitrovic wrote:
> On 3/8/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>> In both cases, you're telling it to catch everything.
>
> Also, catch points should be rare, especially the ones which catch
> base types like Exception or even Error or Throwable. The problem is
> not the syntax, but the way people use exceptions. Pokemon exception
> handling is a bad idiom.

I've given this a fair amount of thought in the past, and I've have extensive experience with making good use out of error handling for managing large code bases that require near real time automated monitoring for defects and rapid repair. My needs may be much more unique than most.

What I will say, is that unless you use an exception handler, and have a well designed exception handling system in place, you will have plenty of problems making use out of frequent try/catch blocks. They may in fact cause more problems than they solve. In a small non essential code base, it may seem pointless as well. So beware that what is good or bad depends entirely on the implementation and the needs.

--rt

On Friday, 8 March 2013 at 17:40:38 UTC, Ali Çehreli wrote:
> On 03/08/2013 12:39 AM, Rob T wrote:
> > In C++ you can do this
> >
> > std::exception Trace()
> > {
> > try
> > {
> > // key item missing from D
> > throw; // <= rethrow last exception
>
> This idiom is know as a Lippincott Function.
>
> Ali

I'm having trouble finding references on Lippincott Function, so if you have any more information, please let me know. Thanks.

--rt

On Friday, 8 March 2013 at 06:05:02 UTC, Maxim Fomin wrote:
>     catch (Exception e) {
>         if (typeid(e) == typeid(myException1))
>             throw e; // may be downcasted, if necessary
>                      // to work with specific fields
>     }


Isn't it better to check identity in this way?

if (typeid(e) is typeid(myException1))

--rt

On Fri, Mar 08, 2013 at 08:52:21PM +0100, Rob T wrote:
> On Friday, 8 March 2013 at 06:05:02 UTC, Maxim Fomin wrote:
> >    catch (Exception e) {
> >        if (typeid(e) == typeid(myException1))
> >            throw e; // may be downcasted, if necessary
> >                     // to work with specific fields
> >    }
> 
> 
> Isn't it better to check identity in this way?
> 
> if (typeid(e) is typeid(myException1))
[...]

Couldn't you just do this?

	auto myExc = cast(myException1)e;
	if (myExc !is null) {
		// do stuff with myExc
	}

?

Or am I missing the point here?


T

-- 
Дерево держится корнями, а человек - друзьями.

On Friday, 8 March 2013 at 19:58:10 UTC, H. S. Teoh wrote:
> On Fri, Mar 08, 2013 at 08:52:21PM +0100, Rob T wrote:
>> On Friday, 8 March 2013 at 06:05:02 UTC, Maxim Fomin wrote:
>> >    catch (Exception e) {
>> >        if (typeid(e) == typeid(myException1))
>> >            throw e; // may be downcasted, if necessary
>> >                     // to work with specific fields
>> >    }
>> 
>> 
>> Isn't it better to check identity in this way?
>> 
>> if (typeid(e) is typeid(myException1))
> [...]
>
> Couldn't you just do this?
>
> 	auto myExc = cast(myException1)e;
> 	if (myExc !is null) {
> 		// do stuff with myExc
> 	}
>
> ?
>
> Or am I missing the point here?
>
>
> T

I didn't know that casting a base class to a derived class that the base does not refer to will resolve to a null. Nice to know.

I suppose that's another way to do the same thing which may be more convenient  depending the situation.

Thanks for suggesting it.

--rt

On Friday, March 08, 2013 19:56:28 Andrej Mitrovic wrote:
> Pokemon exception handling

LOL. I'll have to remember that term!

- Jonathan M Davis

On Friday, March 08, 2013 20:16:13 Rob T wrote:
> If you know of a better way to implement an exception handler in D, then I'd like to know about it. For example I do know that D's system allows you to insert callback functions, but I don't yet know how to make use out of it, so perhaps there's a better way.

If all you need to do is do something when an exception is thrown and don't need the exception itself, then just use scope statements:

http://dlang.org/statement.html#ScopeGuardStatement

scope(failure) doSomethingOnException();
//code that might throw

The block inside the scope statement will run when the surrounding scope is exited with an exception. That _really_ cleans up a lot of code that just wants to react to the fact that an exception was thrown and not actually do anything with it.

- Jonathan M Davis

On Friday, 8 March 2013 at 20:32:23 UTC, Jonathan M Davis wrote:
> On Friday, March 08, 2013 20:16:13 Rob T wrote:
>> If you know of a better way to implement an exception handler in
>> D, then I'd like to know about it. For example I do know that D's
>> system allows you to insert callback functions, but I don't yet
>> know how to make use out of it, so perhaps there's a better way.
>
> If all you need to do is do something when an exception is thrown and don't
> need the exception itself, then just use scope statements:
>
> http://dlang.org/statement.html#ScopeGuardStatement
>
> scope(failure) doSomethingOnException();
> //code that might throw
>
> The block inside the scope statement will run when the surrounding scope is
> exited with an exception. That _really_ cleans up a lot of code that just
> wants to react to the fact that an exception was thrown and not actually do
> anything with it.
>
> - Jonathan M Davis

Yes, scope(...) does seem useful in certain situations.

In my case I need access to the information contained in the Exception object so that I can log what kind of error occurred and also whatever other details there are, and then perform a few general operations such as possibly sending out a notification to support staff.

I am thinking that perhaps a callback may do what I want, so that's something I intend to look at more closely.

--rt

On Friday, March 08, 2013 11:56:12 H. S. Teoh wrote:
> On Fri, Mar 08, 2013 at 08:52:21PM +0100, Rob T wrote:
> > On Friday, 8 March 2013 at 06:05:02 UTC, Maxim Fomin wrote:
> > > catch (Exception e) {
> > > 
> > > if (typeid(e) == typeid(myException1))
> > > 
> > > throw e; // may be downcasted, if necessary
> > > 
> > > // to work with specific fields
> > > 
> > > }
> > 
> > Isn't it better to check identity in this way?
> > 
> > if (typeid(e) is typeid(myException1))
> 
> [...]
> 
> Couldn't you just do this?
> 
> auto myExc = cast(myException1)e;
> if (myExc !is null) {
> // do stuff with myExc
> }
> 
> ?
> 
> Or am I missing the point here?

That's the way that it's supposed to be done. I don't know why anyone would mess around with typeid that.

- Jonathan M Davis

On Friday, 8 March 2013 at 20:46:42 UTC, Jonathan M Davis wrote:
> On Friday, March 08, 2013 11:56:12 H. S. Teoh wrote:
>> On Fri, Mar 08, 2013 at 08:52:21PM +0100, Rob T wrote:
>> > On Friday, 8 March 2013 at 06:05:02 UTC, Maxim Fomin wrote:
>> > > catch (Exception e) {
>> > > 
>> > > if (typeid(e) == typeid(myException1))
>> > > 
>> > > throw e; // may be downcasted, if necessary
>> > > 
>> > > // to work with specific fields
>> > > 
>> > > }
>> > 
>> > Isn't it better to check identity in this way?
>> > 
>> > if (typeid(e) is typeid(myException1))
>> 
>> [...]
>> 
>> Couldn't you just do this?
>> 
>> auto myExc = cast(myException1)e;
>> if (myExc !is null) {
>> // do stuff with myExc
>> }
>> 
>> ?
>> 
>> Or am I missing the point here?
>
> That's the way that it's supposed to be done. I don't know why anyone would
> mess around with typeid that.
>
> - Jonathan M Davis

So this is more efficient or has some other advantages than using typeid?

if ( cast(myException1)e !is null )
{
   // do stuff with myException1
}
else
if ( cast(myException2)e !is null )
{
   // do stuff with myException2
}
else
if ( cast ...

--rt