Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
In Java you can _rethrow_ exceptions, without losing the cause. I.e.:
> catch(SomeException ex)
> throw new MyException(log_state(), ex); //We DO NOT lose the cause
Posted Oct 27, 2012 8:30 UTC (Sat) by ibukanov (subscriber, #3942)
No - with consistent error logging one gets in C very useful stack-like information about the error state without the noise of deep Java stack trace.
Clearly in Java one can do the same and have a stack trace in addition, but even in C it is possible to get the stack trace. Yet the C solution brings less clutter to the server code where it is desirable to log on errors (and only on errors) the maximum information about the state.
Posted Oct 27, 2012 10:41 UTC (Sat) by man_ls (subscriber, #15091)
There are weird occasions where e.g. the Android platform eats up your stack trace and generates its own, but that is not usually the case.
As to checked exceptions, they look good but in practice lead to byzantine exception hierarchies and hyper-delicate error handling, not well suited for humans (or for teams). Unchecked exceptions are good in that you don't need to handle all possible situations. In a web application you can just catch them at the root level, log them and print an HTTP 500 page; the user is not going to care at the moment as to why you are not showing the info they want, and the admins get a nice stack trace -- see above.
Posted Oct 28, 2012 0:09 UTC (Sun) by cmccabe (guest, #60281)
As far as spewing stack traces for normal errors-- people who want this are not thinking clearly. Unless you are a developer, you shouldn't need to read stack traces.
If you do want stack traces in your logs, you can easily get them with: http://golang.org/src/pkg/runtime/debug/stack.go
It's really nice to have stack traces in the language-- lack of them in the language is awkward in C/C++, although there are libraries that can help a lot.
Posted Oct 28, 2012 8:48 UTC (Sun) by man_ls (subscriber, #15091)
Unless you are a developer, you shouldn't need to read stack traces.
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.
Posted Oct 29, 2012 18:31 UTC (Mon) by cmccabe (guest, #60281)
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.
Posted Oct 29, 2012 18:50 UTC (Mon) by man_ls (subscriber, #15091)
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.
Posted Oct 27, 2012 17:37 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds