Passing problems from an API to a plugin

Discussion in 'Plugin Development' started by caseif, Mar 21, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    caseif

    I've been working for a while now on a plugin library, and I'm a bit undecided on how it should handle issues it encounters. Say it has a method called createArena(String), where the parameter is the name. If an arena by that name exists, I obviously don't want it to create another. Ordinarily I would just send an error message to the user creating the arena, but 1) I don't have the user because of the way it's set up, and 2) I want to give the plugin hooking the API to opportunity to handle the problem. So, I could approach this in one of a couple of ways:
    1. Throw an IllegalArgumentException with a detail message explaining the problem. The plugin can then get the message of the exception and call .contains() on it. The downside is that if the plugin doesn't catch the exception and handle it appropriately (I expect the library to be used by newer developers, so they might not even know how), it will print a stack trace to the console and potentially scare the developer/server owner. Additionally, it would be a pain for the dev to have to reference the JavaDocs just to know what could go wrong with a particular method. (It's worth mentioning that this is what I'm currently doing.)
    2. Return an enum value from methods which have the potential to fail. The downside to this is that, well, it's just kind of impractical, and again, there's no guarantee that developers will realize that they should check the return value.
    Which would be a more practical approach, or is there a better one that I'm not thinking of? I'm designing the library with simplicity in mind, but I don't want devs to completely overlook internal failures and end up with a broken frontend.

    Edit: grammar
     
  2. Offline

    FlamingxGamer

    Create your own exception, like ArenaExistsException
     
  3. Offline

    drtshock Retired Staff

    What's wrong with a simple boolean method? If creating the arena was successful, return true, otherwise false.
     
  4. Offline

    caseif

    In certain methods, more than one thing can go wrong, and so I'd like for the plugin to be able to know what the issue is in particular.
     
  5. Offline

    drtshock Retired Staff

    Like what? You said one thing is that what if the arena already exists. Well then why don't you run a check for that before you try to actually create it within the plugin :)
     
  6. Offline

    caseif

    Like I said, I'm creating the library with simplicity in mind, and as such, I'd like to automate as much as possible. As far as multiple problems goes, here's an example: the constructor for the Round class can throw an IAE if the specified arena doesn't exist, or if the world containing the specified arena can't be loaded. There are a plethora of other examples, but that just was the first one I found in the code.

    Hey, that's not a bad idea. I may give that a go.

    The late reply is on account of the fact that I flat-out missed your post earlier. Sorry. :/

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 7, 2016
  7. Offline

    Garris0n

    This is literally exactly what exceptions are for.
     
  8. Offline

    caseif

    The problem with using an IllegalArgumentException is that it's an unchecked exception and thus it's not required for it to be caught. I hadn't previously thought of making a custom exception, though.
     
Thread Status:
Not open for further replies.

Share This Page