IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Disabling assertions
Factored into the mix is the question of performance. Raising exceptions can be an expensive proposition, such that exceptions might ought to be raised only in exceptional circumstances - i.e. those errors which are not part of the normal flow or behavior of the program.

One other factor in the DbC mode of operation is that a lot of people seemed to have disabled the assertions in the production compilation - for reasons of speed. Using an assertion scheme to raise exceptions is fine as long as you don't just use the contracts during the testing phase.
New That's one of the points he raised
Raising exceptions can be an expensive proposition, such that exceptions might ought to be raised only in exceptional circumstances
That's almost word-for-word what he said. He also said that each exception gets pushed onto the stack, which is more expensive than keeping it in memory. I'm not clear on how that's different.

But even if it is more computationally intensive, I think coding to that standard is premature optimization. I think code should be written to be understandable and maintainable until after a bottleneck has been identified. PHP doesn't do checked exceptions, so all you have to do is throw exceptions and catch them where you can handle them. Each function can decide what counts as an exception and each place calling it can decide how critical it is in that context.

So, how much more "expensive" is it to use exceptions rather than returning error objects?
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New Expense is relative
In some cases it might be considered premature optimization, but in those cases where you know the error is (a) normal; (b) frequent; and (c) numerous, then you would want to factor that knowledge into the design. As for why it is expensive, throwing (raising) an error results in an allocation of the Error object with the stack information (used for debugging or catching an exception). Can't recall the numbers for Java but there has been some quantification of the relative speeds of using throw versus returning a result back that captures that an error occurred.

I also might note that there are other ways that libraries handle errors. Typical in floating point operations is to send a NaN (not-a-number) back as the result. The FFPs have a special encoding for this number. A function which returns a list might also return an empty list to indicate no matches. But these are all just variations on manipulating the return result so that errors are encoded within the return value.

Another method to deal with errors has to do with pre- and post-functions that tell you whether an error will occur or has occurred. For example, before you open a file for a read operation, you might want to check if the file exists. The open file operation might throw an exception if the file does not exist, but if you check first, you can avoid that error in the first place. Along similar lines, but less palatable is to have a function which verifies that no error occurs. For example, you might open the file but no error is signaled by an exception or the returned value. Instead, you could call an isOk function after you attempted the file read.

So tell you buddy to make sure to have these extra error handling mechanisms in place to allow the end user to decide how they want to handle the error. Better yet, allow the user to set a property in the object to indicate how they want to handle the errors (ErrorException, ErrorReturnValue, ErrorPreCheck, ErrorPostCheck, etc...).
New Re: That's one of the points he raised
So, how much more "expensive" is it to use exceptions rather than returning error objects?

I've seen a performance test that says that throwing an exception is about twice as expensive as returning an error in PHP. But in either case the cost of the error is trivial compared to the time spent running a script.

The cost does vary a lot by language, in some languages throwing an exception can be an order of magnitude more expensive then returning an error.

Jay
     Question about exceptions - (drewk) - (31)
         Lots of discussions about that - (FuManChu) - (6)
             That only goes for one kind of exceptions! - (CRConrad) - (1)
                 What does the "checked" mean to you? - (FuManChu)
             But he's saying that you should use both - (drewk) - (3)
                 My rule of thumb is, - (Arkadiy)
                 Pick one and stick with it. - (admin)
                 You can do both (or more accurately: either) with or without - (FuManChu)
         Re: Question about exceptions - (JimWeirich) - (23)
             Nice point about responsibility, but grey areas abound - (FuManChu) - (11)
                 Re: Nice point about responsibility, but grey areas abound - (JimWeirich) - (10)
                     No, we don't - (drewk) - (9)
                         The difference is simple - (ben_tilly) - (8)
                             Problem with that - (drewk) - (4)
                                 See? Whether it is an error IS ambiguous! -NT - (ben_tilly) - (2)
                                     I think I know what to do then - (drewk) - (1)
                                         Exactly -NT - (ben_tilly)
                                 Re: Problem with that - (JimWeirich)
                             Thats the sort of logic that makes me wary of exceptions. - (static) - (2)
                                 Exceptions are one form of Continuation - (ChrisR) - (1)
                                     Icon's generators rely on the failure model. - (static)
             Disabling assertions - (ChrisR) - (3)
                 That's one of the points he raised - (drewk) - (2)
                     Expense is relative - (ChrisR)
                     Re: That's one of the points he raised - (JayMehaffey)
             DbC? -NT - (drewk) - (6)
                 Design by Contract - (Yendor) - (5)
                     Not the same thing. - (admin) - (4)
                         That's not strictly Eiffel; - (jake123) - (3)
                             It's built into Eiffel - (admin)
                             It is DESIGN by Contract after all - (JimWeirich) - (1)
                                 As you say - (jake123)

The biggest giveaway is they always have slightly too specific of an answer to literally every question.
60 ms