User: Password:
Subscribe / Log in / New account

RuntimeException ftw

RuntimeException ftw

Posted Oct 28, 2012 8:48 UTC (Sun) by man_ls (guest, #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 (guest, #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.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds