Recent Features
| |||||||||||||
RuntimeException ftwRuntimeException ftwPosted Oct 28, 2012 8:48 UTC (Sun) by man_ls (subscriber, #15091)In reply to: RuntimeException ftw by cmccabe Parent article: Haley: We're doing an ARM64 OpenJDK port!
Unless you are a developer, you shouldn't need to read stack traces.Absolutely true, I did not want to imply that the stack trace is shown to the user. The server displays a regular, nice 500 page (with no mention of "HTTP 500" either); but the stack trace is stored in the logs for further analysis. Exceptions are good also to return from APIs, as long as they are documented: they come out in tests, are easy to spot and understand, and easy to deal with.
(Log in to post comments)
RuntimeException ftw Posted Oct 29, 2012 18:31 UTC (Mon) by cmccabe (guest, #60281) [Link]
I disagree that exceptions should be returned from APIs (shouldn't that be "thrown"?) The caller shouldn't have to understand the internal implementation of your library to use it. A null pointer exception 10 levels deep in library code is not a friendly API, even for programmers.
If you can fail, document how you can fail, and come up with return codes or another API to handle it cleanly. If you can't fail, then return void and be done with it.
Checked exceptions were an attempt to make exceptions "work like return codes." But it failed. Every method in the world ends up throwing IOException, and it basically functions exactly like unchecked exceptions.
RuntimeException ftw Posted Oct 29, 2012 18:50 UTC (Mon) by man_ls (subscriber, #15091) [Link] Sorry, I meant "Exceptions are good also to throw from APIs, as long as they are documented".But throwing a NullPointerException is not what I said; that is obviously a bad idea in any case. Just declare an unchecked exception for every failure condition (with an umbrella super-exception) and document them. That way you can throw them from any point in your code. This is not different from your description: "document how you can fail, and come up with return codes or another API to handle it cleanly". Unchecked exceptions are a wonderful way to handle failures cleanly; in effect these exceptions become another part of your API. IMHO, avoid checked exceptions like the plague because they become, without exception, a mess. In a recent Android app I thought I could get off with a checked exception for offline mode to force implementors to deal with it, but in the end I had to change it back to unchecked.
|
|||||||||||||