31–40 of 129 posts
This is irrelevant, but I just had my first Java experience yesterday. I decided to make an Android app, it's a simple remote control for hobby projects (Raspberry Pi/etc) that gives you a customizable UI with buttons that perform API calls. It'd be pretty simple to do in Python, which is the language I am proficient in, but Android development sounds fun so I wanted to get started in that. Creating the UI was easy e…
This is irrelevant, but I just had my first Java experience yesterday. I decided to make an Android app, it's a simple remote control for hobby projects (Raspberry Pi/etc) that gives you a customizable UI with buttons that perform API calls. It'd be pretty simple to do in Python, which is the language I am proficient in, but Android development sounds fun so I wanted to get started in that. Creating the UI was easy e…
Java is verbose. Tooling is great, however. For exceptions, there are two types. Checked exceptions and runtime exceptions. * Checked exceptions need to be explicitly handled in your code, or it doesn't compile. * Runtime exceptions can just happen, you don't need to check them. I personally don't really like the runtime exceptions because they can hide in thousands of place and throw when you don't expect it. Howeve…
Earlier quoted context omitted.
try { *your stuff* } catch (WhateverYouDontWantToHandleException e) { throw new RuntimeException(e); } Then at the outmost level of your code somewhere you catch RuntimeException and tell the user a general error occurred or something. You will still get the root exception so you can log with stack trace and eventually implement some specific exception handling for it if necessary.
Isn't this the same as "public void myFunction throws WhateverYouDontWantToHandleException" (i.e. letting it propagate up implicitly)?
A RuntimeException, and any subclass of it, is unchecked and so the compiler does not force you to handle it.
Earlier quoted context omitted.
Isn't this the same as "public void myFunction throws WhateverYouDontWantToHandleException" (i.e. letting it propagate up implicitly)?
No, that will force whoever is calling your method to handle that exception, now without knowing the actual context ("why does getWeatherForecast() throw MalformedURLException?" etc.). It also leaks an implementation detail, i.e. the use of URL-whatever. A RuntimeException, and any subclass of it, is unchecked and so the compiler does not force you to handle it.
Earlier quoted context omitted.
Java is verbose. Tooling is great, however. For exceptions, there are two types. Checked exceptions and runtime exceptions. * Checked exceptions need to be explicitly handled in your code, or it doesn't compile. * Runtime exceptions can just happen, you don't need to check them. I personally don't really like the runtime exceptions because they can hide in thousands of place and throw when you don't expect it. Howeve…
Thanks for clarifying checked vs unchecked. Your comment makes perfect sense, and is what I expected. The thing is that I really don't like handling an exception higher than where it makes semantic sense (which is the actual call, in this case), so propagating higher is even less clean, for this specific example. I guess the problem here is the checked exception, but I can see the rationale, if it's impossible to opt…
So somewhere up in your class, you'd write:
private final static URL someUrl;
static {
try {
someUrl = new URL("http://something.com/");
} catch(SomeException e) {
crashAndLogSomehow(e);
}
}
Earlier quoted context omitted.
Well, in more forgiving languages, such as python, you are just implicitly being "hacky" as you put it. E.g. errors - if they ever occur - will happen in runtime. Java tries to move this to compile time, making them visible. It's a tradeoff really.
No, in Python you never silentrly ignore all exceptions (well, you can, but it's a big no-no). You can just opt to not handle them, but they'll crash your program. It's a tradeoff, as I know which exceptions are likely to become a problem and which aren't, and I can choose to handle the relevant ones and let it crash in the rare case that an exception I didn't think likely occurs. In Java, I have to handle malformed…
(I'm a Python dev and hate Java)
Earlier quoted context omitted.
No, in Python you never silentrly ignore all exceptions (well, you can, but it's a big no-no). You can just opt to not handle them, but they'll crash your program. It's a tradeoff, as I know which exceptions are likely to become a problem and which aren't, and I can choose to handle the relevant ones and let it crash in the rare case that an exception I didn't think likely occurs. In Java, I have to handle malformed…
The reason is that Java is designed for enterprise, where "I know which exceptions are likely to become a problem and which aren't" cannot be trusted. With giant code bases and mediocre developers you kind of need to have checked exceptions or you'll have exceptions popping up in the most unexpected places. (I'm a Python dev and hate Java)
Earlier quoted context omitted.
If Java turns you off, you could try Scala on Android. https://news.ycombinator.com/item?id=5873229
I heard that that had very large startup costs due to the Scala VM (IIRC), which is unfortunate for what I'm making (a remote control app) :/
Earlier quoted context omitted.
Thanks for clarifying checked vs unchecked. Your comment makes perfect sense, and is what I expected. The thing is that I really don't like handling an exception higher than where it makes semantic sense (which is the actual call, in this case), so propagating higher is even less clean, for this specific example. I guess the problem here is the checked exception, but I can see the rationale, if it's impossible to opt…
What you could do is initialize the Url in a static block or in a `{{ }}` block and handle the exception there. You would still have the exception handling, but not in your logic, and the static block would ensure that if the Url is indeed malformed, the exception will throw as soon as the class is loaded in memory, instead of only when the Url is instantiated during in logic. So somewhere up in your class, you'd wri…
Earlier quoted context omitted.
I heard that that had very large startup costs due to the Scala VM (IIRC), which is unfortunate for what I'm making (a remote control app) :/
I've used Java for a few years on Android differences for Scala past proguard are minimal for building and performance is the same as it's just compiled Java bytecode and then to dalvik
I will definitely consider it when I know a bit more about it, though, as it seems a much saner language.