Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Matthew J. Clemente
    @mjclemente
    So I’m making a business rule that it needs to be.
    Sean Corfield
    @seancorfield
    An exception says: "Nope, sorry, I don’t know how to deal with this request" (as opposed to "Nope, I know about that but it’s an error").
    Matthew J. Clemente
    @mjclemente
    Is there a preferred way to handle the latter?
    Sean Corfield
    @seancorfield
    Depends on the language context and what the function does / is expected to return.
    For example, functions that "do something" (and return nothing), can return a success / failure indicator instead.
    Functions that return something specific on success, can return nothing on failure (null in Java, for example), or perhaps a struct with a success / failure indicator and a result key when success and a codes key when failure.
    It really depends on what you’re trying to do. There’s no one size fits all here.
    I have my validation functions return arrays of error descriptions, for example. So they return an empty array for success / no errors.
    Lookup functions generally return a "thing" (success) or null (failure).
    I’ll use a boolean result if all I care about is generically "Yes, I did it!" or "Nope, sorry, no can do!".
    Matthew J. Clemente
    @mjclemente
    In this case, in broad strokes, an value is being saved, and then assigned to a “page”. So the value gets validated/saved. Then I pass it into the page bean, which has a function to save the value to a linking table for the page.
    Sean Corfield
    @seancorfield
    (but, again, throwing an exception for "Halp! I haz no cluez!" is still reasonable)
    Matthew J. Clemente
    @mjclemente
    So, right now it returns void… but that’s mostly becuase it’s just doing an insert that I’m assuming is successful.
    The issue is that the page it is being saved to needs to be a “draft”. The page knows whether it is a draft or not.
    But I’d rather insist that my controller (or other calling functions) always make sure they have a draft page called, before they try to save the value.
    (hope I’m explaining this clearly)
    Sean Corfield
    @seancorfield
    Sounds like you’d prefer an exception then, rather than silent auto-creation of the draft.
    Matthew J. Clemente
    @mjclemente
    yeah, only because the silent auto-creation can be expensive
    If there are a number of values that need to be saved (which there can be in some cases)
    Is that lazy? Falling back on the exception?
    Sean Corfield
    @seancorfield
    No, that fits the rule perfectly: you should always create any necessary drafts before calling this function (else it will throw an exception).
    Matthew J. Clemente
    @mjclemente
    Thanks. I guess, returning full circle, it fits with the guideline you provided (is this an expected condition that I should be able to handle?)
    Sean Corfield
    @seancorfield
    Yup. And you’re deciding, from a business p.o.v., that "no, this function should not handle that task".
    Matthew J. Clemente
    @mjclemente
    If the rule (drafts only) makes the condition unexpected, it’s acceptable to throw the exception
    Sean Corfield
    @seancorfield
    Yup!
    Matthew J. Clemente
    @mjclemente
    Thanks! Really appreciate the insight @seancorfield
    Sean Corfield
    @seancorfield
    Any time!
    Matthew J. Clemente
    @mjclemente
    I will be adding that principle to my list of application design guidelines
    Have a great day!
    Sean Corfield
    @seancorfield
    "Halp! I haz no cluez!" :)
    Matthew J. Clemente
    @mjclemente
    hahahaha. I might have to include that in the message
    Sean Corfield
    @seancorfield
    if ( !page.isDraft() ) throw "Halp! I haz no cluez!";
    Matthew J. Clemente
    @mjclemente
    exactly
    Lampei
    @Lampei
    @seancorfield Just wondering if you might be able to answer a question on code structure for unit testing in a Java app (hopefully OK to ask as not a FW1 question)
    I've done unit testing in python and CF and have used the "tests" directory, but I'm seeing a couple of ways to do it in Java...
    projectRoot/src and projectRoot/tests vs. projectRoot/src/main and projectRoot/src/tests
    I didn't know if one way was better than the other. We're going to be (eventually) bring CI into the mix also, so I want to make sure that we're starting on the right foot.
    Lampei
    @Lampei
    I'm not even sure if devs are unit testing their code yet as I'm waiting on SVN access (I'm former dev/QA automation side of things) so it may not even be my decision, but wanted to get an opinion from someone to have some backing on a good way to go forward if we don't do it currently.
    Sean Corfield
    @seancorfield
    @Lampei the src/main, src/tests approach is standard for Maven-based projects. I see it in non-Java projects too when Maven is involved.
    This makes sense once you move away from source-based deployments to build/compile deployments. In the former, you can easily just deploy the src tree. In the latter, it's all source but you choose to compile (and package) just the "main" part of your source code, not all of it.
    Lampei
    @Lampei
    ah, OK. Haven't done much with Java up to this point, but it's all just code, right? :smile:
    Sean Corfield
    @seancorfield
    If you’re lucky, you’ll be working with Gradle rather than Maven...
    Maven makes Ant seem like fun. At least with Gradle, you don’t have to <program><in html="as a language"/></program>
    Lampei
    @Lampei
    Yeah, that's something else I've been meaning to check out a bit more too. Haven't had much need to do anything with it up to this point, but I started to look into it a little with some Android builds.
    Lampei
    @Lampei
    Well that Gradle site sucked me in for 30 minutes of reading in no time flat :smile: Just reading through the initial how-to's that's got some powerful features to it...and like you say, is much more readable than Maven.
    Sean Corfield
    @seancorfield
    As a Clojurian, I rely on Boot (now, previously I relied on Leiningen), even when working with Java in my own projects.
    Matthew J. Clemente
    @mjclemente
    I’m working on standardizing some of our naming conventions. Within our services, we frequently have get( id ) and check( id ) methods. The former returns a populated bean, the latter a boolean. There may also be convenience methods, like getByName( name ) or getDraft( id ). Under the hood, they all utilize a private method, which returns the result of a query, based on the parameters. I’m trying to name that private method. I initially used getByProperty( id ), but it bothers me that the name doesn’t differentiate it from related public methods that return objects.
    So my question is, should that method name somehow indicate that it is private and that its return type is different?
    Matthew J. Clemente
    @mjclemente
    thinking out loud here, but I may go with something like readByProperty( args ) and establish the internal convention that get prefixes methods that return objects and read is for private methods that actually query for the data.
    Sean Corfield
    @seancorfield
    Sounds reasonable. FWIW, we have get... for an object and find... for an array of structs, and then get…Iterator for an IBO (multiple objects).