Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm writing a class in java (for android) that accepts an org.w3c.dom.Element as input and provides some business logic functions around it. In one of those functions, I call getElementsByTagName and expect only 1 element in the returned NodeList. If there's more than 1 element, it means the Element I got is jacked up somehow and I need to throw an exception. Is there an exception already included in JDK7 which is made to accurately represent this problem?
You could make the method throw an IllegalArgumentException:
Thrown to indicate that a method has been passed an illegal or inappropriate argument.
Or you could write your own Exception class which may be a better solution if you're following this exception-driven approach.
Note however that using exceptions for flow control can cause lower performance.
It's best to define your own Exception, as none of the Java defined exceptions quite fit the case you're experiencing, and it doesn't seem that people outside your organization need to understand the thrown exception.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Why does Java not support a nice and readable direct print-out for arrays?
I do know that Arrays.toString can be used to get that, and I also know what the hashcode output means (as explained in Why does the toString method in java not seem to work for an array).
But I am asking myself why the developers did not choose to make arrays directly print the readable representation.
Is it technically impossible? Would it impact performance?
arrays in java are a special case. There is no java source code for an array class and arrays are implemented in the JVM directly.
Given that, arrays don't have any methods themselves and they do not override any of the default Object methods (Yeah they're treated as objects but they're handled with special bytecodes).
As for why the decided to do that it probably has to do with allowing more flexibility with creating arrays of different types and dimensions, maybe processing speed as well.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In Java 8, the Optional class is implemented as a final container class that defines isPresent depending on the value being null. That means that it is not possible to have an Optional(null), which although not commonly used, seems like a design flaw to me. In particular, this defeats the purpose of having an optional in the first place, because you can simply set a variable to null and do the usual if (x != null), without the overhead introduced by Optional. Furthermore, the Optional class has to check if the value == null for every single operation performed on it.
In Scala however, the Option trait is much more sophisticated: It has the Some subclass for existent values and the None subclass for non-existent values. This eliminates the need for null-checks inside the class and allows Some(null) values.
My question is why the Java designers chose not to follow this subclass principle as well.
Java has empty() and ofNullable(null). Other tool methods exist too. Scala uses subclassing, case classes where other languages (still) use other notions. Scala sees typing a bit more operational.
Java Optional is workable; come with code examples. Using a Stream for an Optional might be more in the character of Scala maybe, allowing fluent design with chaining calls in a bit more comfortable way.
It lives with null and is more a recommendation as you stated.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am well aware that the void keyword is used to indicate in a method declaration that the method will return no value. My question is not about - to use an analogy - how to use the car, but rather about what's underneath the hood. I would like to know why void actually needs to be specified, i.e. does Java reserve an internal variable of some sort to keep track of return types? Will setting a method to void make it so that it doesn't have to do this?
Another way to put it is to ask why, exactly, can't Java omit the void keyword and assume that if there is no returned type than the method is void? I think that there is something to do with how Java might "prepare" to handle the return type, and possibly something to do with optimization... please use full detail.
Its a java language Specification
void used with only methods declaration
if we omit void then its treated as constructor.
SEE THIS
my answer is a bit of a guess. But I'd say its to protect the developer against just forgetting to declare the return type. Sure the compiler can even by default be programmed to render undeclared return types void. But that would be at cost to the aid for the developer.
Furthermore, IDEs would have to anticipate on the same.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
For example if I was making an image API in Java would it be more beneficial to have multiple exception classes such as ImageSizeException, ImageFormatException or have a single exception class such as ImageException which has a string, enum ect for what kind of exception it is.
As a secondary question if you use multiple exception classes would it be more acceptable to group them in an exceptions package or with the classes that would throw them
You should certainly have a base exception, ImageException, which is the superclass of any others. Like Java has IOException.
Personally I would prefer one Exception with an Enum or int to subtype, but typical Java style is to have a lot of Exception subclasses. Your should probably follow convention.
It's Better to have many exceptions.it will be easier debugging when your code is huge,and you could have ImageException as the superclassfor all these exceptions.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
why we use 'Throws IOException' in java File handling. i mean what is the purpose of using these two words in File handling??
Please help...
You are probably referring to checked exceptions. They are used to indicate that a method could potentially throw one of the listed exceptions so that the callers need to explicitly catch them or be marked with the same exceptions list.
The throws word means that the code could enter an error state, the IOExeption word describes the error state.
This means that you will have to put any method that throws IOExcepion into a try ... catch block where you can write code to make your program respond to the error state appropriately.