This discussion is archived
11 Replies Latest reply: Jul 21, 2012 4:07 PM by jschellSomeoneStoleMyAlias RSS

How do you handle C error codes in Java properly?

702598 Newbie
Currently Being Moderated
So i've got this C function I need to call from Java. The C function represents error codes as int values. So I have 10 possible error codes that this C function can generate, but it will only return one at a time per call. I thought about creating 10 checked exceptions for this native call and throwing the exact exception by translating C error code to Java checked exception. Whats the standard way to do this, or am I already doing this correctly.

I do understand, sending back the int value and a message string back to Java is bad idea as this is not how Java deals with exceptions. I've created a parent exception class and 10 children in case someone wants to take some generic action for all exceptions.

Any idea?
  • 1. Re: How do you handle C error codes in Java properly?
    gimbal2 Guru
    Currently Being Moderated
    user3009713 wrote:
    I thought about creating 10 checked exceptions for this native call and throwing the exact exception by translating C error code to Java checked exception. Whats the standard way to do this, or am I already doing this correctly.
    There is no standard way. Its not like everyone is doing what you're doing on a daily basis, most of us try to avoid hooking up native code to a Java program to begin with.

    The question then becomes: is it a good idea? That's a personal opinion - if you think that's what you should do then just do it. Its your code, you have to live with it. Me: I'd just throw one exception but with a message that matches the error code.
  • 2. Re: How do you handle C error codes in Java properly?
    702598 Newbie
    Currently Being Moderated
    The reason for throwing unique exceptions is that the client code will be doing a specific action for each exception. If I just throw one generic exception (msg and int error code value), then the client code ends up doing if test on the int value to perform specific action.

    But this gets messy as the number of possible errors grow with other libraries that I might be interfacing. What makes sense to me is to have unique exceptions that translate C error flags to java exceptions (because I except a reasonable catch handle), then if that error list is really long, it bloats client code, even though you writing the interface determine the client should do something about the exceptions being thrown.
  • 3. Re: How do you handle C error codes in Java properly?
    gimbal2 Guru
    Currently Being Moderated
    user3009713 wrote:
    The reason for throwing unique exceptions is that the client code will be doing a specific action for each exception.
    That's a very good reason to throw dedicated exceptions.
    If I just throw one generic exception (msg and int error code value), then the client code ends up doing if test on the int value to perform specific action.
    But don't you have to check the code anyway to be able to throw a matching exception?
    But this gets messy as the number of possible errors grow with other libraries that I might be interfacing. What makes sense to me is to have unique exceptions that translate C error flags to java exceptions (because I except a reasonable catch handle), then if that error list is really long, it bloats client code, even though you writing the interface determine the client should do something about the exceptions being thrown.
    There is a big what-if in there: it gets messy IF you interface with other libraries.

    Yeah, so what? There is also a good chance you might not. I hope you do everything in your power to keep this contained. Otherwise you end up with automated chaos.
  • 4. Re: How do you handle C error codes in Java properly?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    user3009713 wrote:
    So i've got this C function I need to call from Java. The C function represents error codes as int values. So I have 10 possible error codes that this C function can generate, but it will only return one at a time per call. I thought about creating 10 checked exceptions for this native call and throwing the exact exception by translating C error code to Java checked exception. Whats the standard way to do this, or am I already doing this correctly.
    You have a method that returns a value.

    Seems like the "standard" way to do that would be to have a method (java) that returns a value.

    > I do understand, sending back the int value and a message string back to Java is bad idea as this is not how Java deals with exceptions.

    There is a difference between "exception" and "error" in a general sense. Coding either or both general ideas can be done (for either case) as and exception or a return value. The choice is often based on what the caller, not the called, code will do.
  • 5. Re: How do you handle C error codes in Java properly?
    702598 Newbie
    Currently Being Moderated
    gimbal2 wrote:
    user3009713 wrote:
    The reason for throwing unique exceptions is that the client code will be doing a specific action for each exception.
    That's a very good reason to throw dedicated exceptions.
    If I just throw one generic exception (msg and int error code value), then the client code ends up doing if test on the int value to perform specific action.
    But don't you have to check the code anyway to be able to throw a matching exception?
    This checking is happening in the JNI code, not in the client code.
    >
    But this gets messy as the number of possible errors grow with other libraries that I might be interfacing. What makes sense to me is to have unique exceptions that translate C error flags to java exceptions (because I except a reasonable catch handle), then if that error list is really long, it bloats client code, even though you writing the interface determine the client should do something about the exceptions being thrown.
    There is a big what-if in there: it gets messy IF you interface with other libraries.

    Yeah, so what? There is also a good chance you might not. I hope you do everything in your power to keep this contained. Otherwise you end up with automated chaos.
  • 6. Re: How do you handle C error codes in Java properly?
    702598 Newbie
    Currently Being Moderated
    jschell wrote:
    user3009713 wrote:
    So i've got this C function I need to call from Java. The C function represents error codes as int values. So I have 10 possible error codes that this C function can generate, but it will only return one at a time per call. I thought about creating 10 checked exceptions for this native call and throwing the exact exception by translating C error code to Java checked exception. Whats the standard way to do this, or am I already doing this correctly.
    You have a method that returns a value.

    Seems like the "standard" way to do that would be to have a method (java) that returns a value.
    I do understand, sending back the int value and a message string back to Java is bad idea as this is not how Java deals with exceptions.
    There is a difference between "exception" and "error" in a general sense. Coding either or both general ideas can be done (for either case) as and exception or a return value. The choice is often based on what the caller, not the called, code will do.
    I understand exception to be a error handling mechanism for Java. If you return int values back to client code, then client will have to throw exception, and eventually you'll end up with multiple programming patterns in different clients. I certainly want to prevent that. Thats why I want to throw the exception from JNI and let the client(s) do the action. Ofcourse the clients can catch my exception and throw something completely different that is appropriate for them, and thats totally acceptable to me.
  • 7. Re: How do you handle C error codes in Java properly?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    user3009713 wrote:
    There is a difference between "exception" and "error" in a general sense. Coding either or both general ideas can be done (for either case) as and exception or a return value. The choice is often based on what the caller, not the called, code will do.
    I understand exception to be a error handling mechanism for Java.
    As I said - the implementation is different than the idea.
    If you return int values back to client code, then client will have to throw exception,
    If your business needs dictate that your client when it receives a certain error code (from the C API) should exhibit the idea of an excepition then...your java code should in some way produce an exception.

    That statement however is different than the general one that you made.
    and eventually you'll end up with multiple programming patterns in different clients. I certainly want to prevent that.
    No idea what that statement means.
    Thats why I want to throw the exception from JNI and let the client(s) do the action. Ofcourse the clients can catch my exception and throw something completely different that is appropriate for them, and thats totally acceptable to me.
    That has nothing to do with what I said.

    You seem to be confusing the idea with the implementation. The idea is expressed in the architecture/design and is a consideration which has nothing to do with semantics of the language.

    The implementation is the expression of the architecture/design.

    And I can choose to express an exceptional condition which originated from the architecture/design (idea) either as a return value (implementation) or as an exception (implementation.) The later is often the best choice.

    However if I have no idea what the architecture/design is then there is no criteria for deciding how to express something in the semantics of a target language (java or anything else.)

    And since you have not posted any business needs here then, again, the BEST way to express a C API that returns an error code is via a Java method that also returns an error code.
  • 8. Re: How do you handle C error codes in Java properly?
    EJP Guru
    Currently Being Moderated
    If your business needs dictate that your client when it receives a certain error code (from the C API) should exhibit the idea of an excepition then...your java code should in some way produce an exception.
    Business needs do not dictate programming techniques and interface designs. They dictate requirements, needs, and features.

    @OP Programming interfaces are contracts between programmers, and need to be discussed with the people writing the client code. If that's you, make a pragmatic decision: you are into the area of API design. I would certainly throw exceptions, as many different ones as you think you really need. Not too many of course :-|
  • 9. Re: How do you handle C error codes in Java properly?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    EJP wrote:
    If your business needs dictate that your client when it receives a certain error code (from the C API) should exhibit the idea of an excepition then...your java code should in some way produce an exception.
    Business needs do not dictate programming techniques and interface designs. They dictate requirements, needs, and features.
    Your business might not do that but the ones that I have been in can and have done that explicitly.

    Your business might also not define problem domains but mine do and those problem domain provide an implicit context which leads one to create a design that uses one or the other.
    @OP Programming interfaces are contracts between programmers, and need to be discussed with the people writing the client code.
    And of course if the "people" writing the client code are in fact other other companies or even groups within a larger company then the definition of those companies requires a business requirement.
  • 10. Re: How do you handle C error codes in Java properly?
    EJP Guru
    Currently Being Moderated
    Your business might not do that but the ones that I have been in can and have done that explicitly.
    You are really going to have to explain to us what kind of business requirement could dictate the choice between return codes and exceptions.
    Your business might also not define problem domains
    I haven't said a word about problem domains. Please stick to the topic.
    And of course if the "people" writing the client code are in fact other other companies or even groups within a larger company then the definition of those companies requires a business requirement.
    I don't know what any of this means. A 'definition' of companies 'requires a business requirement'? You seem to be arguing in circles here. An API design is dictated by a business requirement, and if there isn't one, one is required anyway?
  • 11. Re: How do you handle C error codes in Java properly?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    EJP wrote:
    Your business might not do that but the ones that I have been in can and have done that explicitly.
    You are really going to have to explain to us what kind of business requirement could dictate the choice between return codes and exceptions.
    I thought you understood business requirements. So an example would be where the customer has the following in their requirements document which is part of the contract.

    "When the map file is not found the API will return an error code of -37".

    (Without a business requirement then one might make a design/implementation decision to throw an exception when the map file does not exist.)
    Your business might also not define problem domains
    I haven't said a word about problem domains. Please stick to the topic.
    Business needs are wrapped up in a problem domain space. Always.
    And of course if the "people" writing the client code are in fact other other companies or even groups within a larger company then the definition of those companies requires a business requirement.
    I don't know what any of this means. A 'definition' of companies 'requires a business requirement'? You seem to be arguing in circles here. An API design is dictated by a business requirement, and if there isn't one, one is required anyway?
    You suggested that there is no possibility of business requirements dictating a design/implementation decision. There are in fact business requirements that specifically define APIs. A contracting company might be required to deliver a product that exposes such an API and/or might be required to deliver a product that interacts with a customer API. In those circumstances not explicitly defining the API, in either case is at best foolhardy and at worst making it impossible to determine if the delivered product meets the goals of the customer.

    And yes I have seen and even created explicit business requirements like that. Presumably you have not.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points