On 26 March 2011 16:13, Reinier Zwitserloot <[email protected]> wrote:
> On Saturday, March 26, 2011 1:50:40 PM UTC+1, Josh Berry wrote: >> >> I like how you call foul all the time on other people's rudeness, yet >> feel free to call any design you don't care for silly on a whim. >> > Because I mean it. Given an API which as designed, returns void, but which > needs to deal with errors (as I explained). Anybody that suggests the right > way to return errors from this construct is by having a return value that > needs to be inspected, especially if its banking stuff, is an idiot. I'll go > to bat and defend my standpoint, but I doubt I have to. Are you honestly > going to argue this? > You have a method that returns void, to be used in backing software. That gives you 3 possibilities: 1. It does nothing. 2. You've written it in continuation passing style. 3. It relies entirely on side-effects to get the job done. Given that "doing nothing" is a role better assigned to most bank CEOs as opposed to most bank software, I'm going to rule out that likelihood. CPS? This is where you you never return from a function, instead passing another function to be executed next. In Java, this is a little unwieldy and means SAM types. Your expressed preference for big stack traces leaves it as a possibility, but I'm going to also rule it out given the remaining description of the system and the fact that it's a relatively uncommon style to use, especially outside of FP-biased languages. So your entire method works through side effects... This means that you won't have referential integrity, that you can guarantee repeatable behaviour for the method given the same inputs. Putting aside other aspects of imperative vs declarative programming, this raises some big issues when it comes to testing. In order to test it, you're going to need a large test harness set up to provide the necessary context for these side effects. It also means that consistency and atomicity will be hard to achieve, as you're likely performing multiple side effects with a time difference between them, so if this'll run on a multi-threaded system then you have to be careful with locking/synchronisation (notoriously difficult) or you'll have to rely on some external system to provide an external transactional context (a database, I suspect), so that's another dependency to add to your test harness. Given this design, it's almost certain that you'll have fewer, larger, unit tests that aren't run often enough because they're just too slow. If it runs true to form, you'll likely also have low test coverage, due to the difficulty of arranging the necessary mock database and transactional context. All this in a piece of software that's potentially dealing with vast sums of money, and needs to be made as safe, reliable, and well tested as is possible. A goal that appears to be threatened by the rampant use of side-effects, yet you describe any alternative API that uses return values as being idiotic. Unsurprisingly, I find myself unable to agree with your evaluation here -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
