I read your post “Checked Exceptions are Waste”. I had a similar post: http://tri-katch.blogspot.com/2016/02/java-checked-exception-is-bad.html.

I have been thinking about redesigning exception mechanism (not only limited to Java) for 9+ years (http://www.theserverside.com/news/thread.tss?thread_id=43820#225361). And Here is the result:

http://tri-katch.blogspot.com/2015/05/catch-code-proposal-to-expand-catch-in.html

Could you take a look and comment? If possible, I would like to join forces with others to improve exception mechanism in all languages (in the same process, make checked exception completely obsolete – I wish we can eliminate it but that does not seem to be possible).

Thanks.

Bo

And not only that, but also the fact that we should actually be using checked exceptions for everything, but there’s a big (but easily fixed) problem with the implementation of them in Java (and any other language for that matter in regards to regular unchecked exceptions). I also include a proposal for a solution by making a small language adjustment.
In a nutshell, checked exceptions should automatically be converted to unchecked (runtime) exceptions when they are not caught or rethrown. That way you almost exclusively deal with (throw and catch) checked exceptions (which I call functional errors) originating directly from the called function. Unchecked exceptions (which I call internal errors) are only to be caught at specific places in code (perhaps only the main() function) to log them and display a “Something went wrong, check the logs” message to the user.

Example: when calling login() I would like to catch UserNotFoundError and PasswordIncorrectError to display a useful error message on the login screen that the user should check the username and password and try again. I don’t care about any DatabaseNotFoundError, IoError, ConnectionLostError, etc. etc. because I can’t handle such errors originating from deeper functions called by the login function. Those are internal implementation details and need to be dealt with at another level in the application.

This is the link to the article:
http://blog.bitethecode.com/post/130259363012/exceptions-dont-excist

The pun in the title is intended.

I disagree (strongly) with the idea of exceptions being exceptional. They’re actually a half-arsed implementation of Lisp conditions (see Greenspun’s tenth rule)

I use exceptions when there is no point in the current logic path continuing. In the VendingMachine example, my friend Liz was able to write a Swing GUI that caught the exception and displayed it as an error message on the LCD display. Quite a result!To do that with return flags, I’d have to check the return flag, and then probably return a return flag to my caller, who’d have to return a return flag to his caller… and so on and so on.

Also, out parameters, by their very nature require mutable state… Not for me, thanks.

This is a prime example of where a result flag + out params is appropriate.

bool GiveMeaDrink(out Drink)

So now you know if it’s safe or not off one call. If you need to know why give some way to get that info. But really you’re looking into the state of the vending machine at that point and it doesn’t really need to tell you since you already know you were supposed to provide the adequate amount of money first.

You could argue that it’s better to check state first then call. However that’s only partially successful since it would fail in a threaded environment.

however the point is Exceptions are “exceptional” (hense the name) not “normal” you didn’t give me enough money so you can’t have a drink is not exceptional in anyway. You just need to learn how to count your change better.

tell application “Adium” to go away with message “Pomodoro in Progress”

tell application “Adium” to go available

Thanks!

Good point. I have used Call Hierarchy, although when I read your comment, the idea that popped into my mind was “debugging”. 
I use “Find references in workspace (<ctrl><shift>g)” a lot while refactoring (particularly while deleting code), but not Call Hierarchy. I’m not sure why; I’ll investigate that feeling next time I’m doing something like this.

Also, yes, the point of this is to leverage the compiler to help make sure we’ve removed all traces of the original null. I hate null checks within code I control, as that is indicative of a bad citizen (see Good Citizen)

Just a little contribution: Many ideas do have a way to search for references hierarchically. I now for sure that in Eclipse is called “call hierarchy”, but I am quite sure that on Idea is possible too, but I do not know the shortcuts 🙂

Still, the “it won’t compile”  technic does prevent you from missing any case.

Good point. Although I would hope (for my sanity) that if there are catch everything blocks in the code, that they’re doing something sensible and I don’t need to go and change them at this point.
(I’ll probably go and rip them out at the soonest opportunity though 🙂 )

Yes, although the advantage of this method is that it propagates _beyond the direct usages_.

The advantage is that it highlights the direct and indirect usages of someMethod. Direct usages is obviously trivial, it’s the indirect usages where the bugs usually lie.