== Quote from Jonathan M Davis (jmdavisprog@gmail.com)'s article
> On Saturday 31 July 2010 20:15:58 Jason Spencer wrote:
> > == Quote from Dmitry Olshansky (dmitry.olsh@gmail.com)'s article
> >
> [...snip]
> >
> > Just a thought.
> > Jason
> I honestly don't think that exception handling is a particularly expensive solution in most cases. When dealing with an error, it's likely to either be related to I/O (be it an actual I/O error or input from a user or file) or a logic error in the code.
I have seen code which tries toInt and then does toFloat in the catch. Not sure
whether it was just bad code (looks like it though) but there are probably some
examples where people really don't know what kind of data they are handling and
use std.conv to try.
Not really sure about that now that I think about it.
~~
:Pluto

Jason Spencer Wrote:
> Unless D has made great strides in exception
> performance (which is entirely possible),

From my tests dmd exceptions are more than ten times slower than Oracle-Java ones. I have test code.

Bye,
bearophile

== Quote from Jonathan M Davis (jmdavisprog@gmail.com)'s article
> For logic errors, efficiency isn't really an issue, since they shouldn't be happening. If they are, go fix your code and it won't be an issue.

That gets less true as the cost of a try block goes up.  Even if logic errors never occur, the infrastructure to check for them costs you something.  Ever compared the performance of a program w/ and w/o trys?

So, would you advocate for exceptions as the sole error reporting mechanism?  Return values are just for valid result values and everything else is an exception?  Where do you personally draw the line?

Jason

On Sunday 01 August 2010 07:36:27 Jason Spencer wrote:
> == Quote from Jonathan M Davis (jmdavisprog@gmail.com)'s article
> 
> > For logic errors, efficiency isn't really an issue, since they shouldn't be happening. If they are, go fix your code and it won't be an issue.
> 
> That gets less true as the cost of a try block goes up.  Even if logic errors never occur, the infrastructure to check for them costs you something.  Ever compared the performance of a program w/ and w/o trys?
> 
> So, would you advocate for exceptions as the sole error reporting mechanism?  Return values are just for valid result values and everything else is an exception?  Where do you personally draw the line?
> 
> Jason

It really depends on what you're doing. I do think that exceptions are the better way to go, but it tends to be dangerous to say things like "always" and "never." Generally, however, I would use return for valid results only and use exceptions for errors. However, if error cases become very likely, then exceptions do tend to become a poorer solution since you don't want to be throwing lots of exceptions. Also, there are cases where you can take an error and simply turn it into a default value (particularly for things like parsing and conversion functions) if that's acceptable.

Still, I think that it generally makes for better code when you assume that the returned data is correct and then let exceptions deal with the error cases - particularly when dealing with user input and file I/O. And in such cases, efficiency is not generally the greatest concern. If you had cases where efficency was a great concern, then it might be worth looking at whether exceptions were the best way to handle things, but in the general case, I believe that they are.

As to where exactly I draw the line, I'd really have to look at the code in question to make any kind of judgement call. However, I'm generally going to go with exceptions unless I have a good reason not to, and I've found such reasons to be fairly rare.

- Jonathan M Davis