Exceptional baseball pitching machine



  • Today I just came across an important method in a important third-party library. Let me show you its signature.

    public void verify() throws CertificateException, NoSuchAlgorithmException, InvalidKeyException, NoSuchProviderException, SignatureException, CertificateExpiredException, CertificateNotYetValidException, CodingException, PKCSParsingException, TicketException, Exception

    I share this because the final Exception made me chuckle. "We don't know what else may be coming your way so just watch out!"



  • But at least it will not be an Error.

    Wait, are you saying that Error is exempt from the declaring Throwables rule? Darn.



  • I like how the developer just gave up in the end and added Exception to the list.



  • @Xyro said:

    CodingException
     

    This whole thing is a coding exception.



  •   throw new CodingException("The programmer who wrote this method was exceptional. As a result, this method's code is exceptionally stupid").

    also, i assume that all the "parameters" to this method (key, certificate, algorithm, etc.) are given in the form of assigning to properties of object which contains the method before calling it?



  • @SEMI-HYBRID code said:

    also, i assume that all the "parameters" to this method (key, certificate, algorithm, etc.) are given in the form of assigning to properties of object which contains the method before calling it?

    Mostly, yes, but you have to be careful of the internal state of the object. For example, it needs to be in VERIFY mode with a state of INITIALIZED (or maybe START, too?). If it's still in CREATE mode, it'll throw a WrongTicketModeException. To switch modes, you either have to call the setMode() method yourself, or call the setTicket() method and pass in a byte array (or base64-encoded byte array) of its properties and certificate signatures in order to switch modes for you.

    The object's name is Ticket, so you usually end up calling ticket.setTicket(someString), which is a bit odd but whatever. Using that technique also validates but not verifies the arguments passed in. Passing in the properties one at a time does not validate them nor verify them. (When I say "validate", I mean to say that the arguments are sanity-checked. This is not to be confused with the isValid() methods, which merely checks if the Ticket has not yet expired.) However, getting the properties values back out of the object requires it to be VERIFY mode. In other words, you can't use a partially initialized object to pass around to get and set properties. The properties must all be set and verified in order to access them.

    The Ticket can either be in CREATE mode, in which you can pass in arguments, or VERIFY mode, after it gets verified and you can get arguments out of it. There's also that setTicket() method which sets and resets the whole object, but it only allows a giant byte array as its argument. I think there's also a CREATED mode, that's used when you call the create() method, but I'm not entirely clear as to where in the state machine that fits, because using setTicket() also "creates" the ticket by filling in the Ticket object's properties. Either way you're probably going to be calling ticket.setTicket(string) or ticket.setProperty(blah) and then ticket.create(). Oh, and make sure the ticket is in VERIFY mode before you call the verify() method or else you'll get a WrongTicketModeException from that, too.

    Additionally and independently of this is another internal state (simply called "state") which values of START, INITIALIZED, and VERIFIED. Some of the object's values can only be accessed if the mode is VERIFY but the state is VERIFIED. So like, I guess they can only be gotten during the verification step? None of the properties can be accessed in the START state. Unlike the mode, the state cannot be set externally.

    To be fair, I don't think it's really meant to be used in client code, despite the fact that you kind of have to. Reverse engineering its raw byte structure was a fun challenge, and now I understand how to use Perls' pack() and unpack() like a pro.



  • Sounds like someone needs to use the Builder Pattern... ?



  • @zelmak said:

    Sounds like someone needs to use the Builder Pattern... ?

    Or the Solve Every Problem By Naming A Pattern Pattern.



  • @blakeyrat said:

    Or the Solve Every Problem By Naming A Pattern Pattern.

    I have a coworker who uses that pattern. He mostly never knows what he's talking about.

    He also saves off "templates" of the "patterns" for "reuse" in later development. What that really means is that he copies and pastes code over and over for each new code unit. More than once we've had to go back and fix all of modules that use one of his broken "patterns". Recently, we've discovered a huge problem with a few hundred of them. We were supposed to fix them a year or so ago, but it's such a daunting task it hasn't been tackled yet. Ugh.


Log in to reply