Re: Design: Custom Exception Usage

On Fri, 11 Apr 2008 02:28:53 -0700, Anthony Jones <Ant@xxxxxxxxxxxxxxxx> wrote:

I wouldn't want that at all. If I'm calling CanParse(), 99 times out of a
100 it's because I want to parse the string. It'd be silly to call a
method that basically has to do the work of parsing the string, but which
only returns a flag telling me if actually parsing the string will work.

Well thats the crux of the matter isn't it? Why is it "silly" ?

Just my opinion, granted...but it's "silly" because you are doing the same thing twice. Each time you return a different kind of result: the first time, you return "did I succeed?", the second time you return "the outcome of my success". But the work leading up to that is basically the same.

[...]
If anything the "Try..." pattern is a great example of the usefulness of
by-reference parameters.

Its also an example of obscurity of function.

As Marc pointed out, the "Try..." pattern isn't obscure. Later you wrote "it may become part of the expected structure of code". Sorry to break the news to you: it's _already_ used so often that it's a standard pattern in .NET.

[...]
You write "forced" as though there's something about calling TryParse()
that is harmful.

No I wrote "Not having CanParse I'm forced ...". Its not the presence of
TryParse as an option which bothers me its not having a CanParse that I have
issue with.

That's not what I meant. Your statement seemed to imply that you find something wrong with the "Try..." pattern. The rest of your post seems to say that too.

For what it's worth, you could easily write your own "CanParse". It would be trivial. You aren't forced to use the "Try..." pattern at all.

[...]
Why is it the case that "how did x get assigned a value" is "not that
obvious"? The "out" in the parameter list for the call to TryParse()
makes it very clear where x is getting assigned.

Its a relative thing. True it isn't actually hard to see that the out
keyword on the parameter indicates where x gets its value. However it is
harder to see than x = because that's what our minds will be condition to
expect when looking for an assignment. This may seem to be a microscopic
and insigniifcant difference but to think so is a mistake.

Okay. I do have sympathy for the question of what your brain sees versus what the compiler sees. In this particular case, I don't have any trouble seeing what the compiler sees, but I've been in other situations where I do, so I'll grant you that you yourself may have trouble with this.

Still, I think it's a scenario worth retraining yourself for. The "Try..." pattern isn't going away, and it provides a performance benefit for trivial effort on your part. I agree most of the time it's not a needed performance benefit, but I don't think this is a scenario where the non-performant variation carries some huge benefit over the performant one from a readability point of view.

Is it really that hard to teach yourself to recognize passing by-reference semantics?

[...]
The same principle can be applied to readability of code. Small differences
such as CanParse/Parse vs TryParse only have a small effect individually on
readability however the cumalitive effect of computer oriented over human
oriented coding is significant.

I guess this is where we simply will disagree. I don't find by-reference parameters hard to read in code, and on top of that, while I agree that they should be used very sparingly, they are an important part of the language and it's my opinion that if you're having trouble recognizing the pattern, the solution is to spend more time with the language so that the pattern is recognizable, rather than to change the framework so that you can call the same thing twice with slightly different semantics each time.

As I said, I have sympathy for your position -- readability is a pet project of mine too -- but I think that in this case you'll be better served by drinking the Kool Aid. :)

[...]
If performance is not a concern (and you already wrote that it almost
never is), you can always just wrap a call to Parse() with a try/catch
block. That provides the exact assignment pattern you're asking for.

That simply replaces one unusual pattern of code with another. Not a
solution to the human problem I'm looking for.

This I don't understand. All that the try/catch adds is a few more lines. The assignment is right in there, just as you've expected. That said, you could always add the CanParse() method yourself.

So, I'm curious: have you? Is this really important enough to you that you've dealt with the problem? Or is it just something you'd rather just complain about?

[...] It would be nice to have the choice of all three but if I
could only have two I would take CanParse and TryParse. Sadly I only have
the one TryParse.

That's not really true. You can add both the CanParse() and the nullable return value pattern to your own code, trivially.

[...]
ByRef parameters are unusual and can catch the less wary out. They can be
gotchas even for the experienced. Whilst they do have their place they
should be used sparingly and be treated with suspicion. In short, they
smell bad.

I'd say that's the other place I disagree. Granted, "smell bad" isn't a techincal phrase anyway, so by its very nature using it is going to be imprecise. But I don't think a particular pattern "smells bad" just because it should be used sparingly.

Maybe you're just using the phrase differently from the way I'd use it. For me, code only "smells bad" (inasmuch as it could have a smell :) ) if and when something is used inappropriately. If it's something that should be used sparingly, but it's still being used appropriately, then that's fine-smelling code.

Pete
.

Loading