Java degree desirable
-
Interesting how you see it as a benefit of checked exceptions - I see it as a detriment; By explicitly stating that printPaycheck throws a Database / Network exception, you've just tightly coupled it to a database and network.
There is no chance of lifting out functionality to an interface in a sane manner.
Checked exceptions simply do not work with generalised concepts like interfaces.
-
@Salamander said:
Interesting how you see it as a benefit of checked exceptions - I see it as a detriment; By explicitly stating that printPaycheck throws a Database / Network exception, you've just tightly coupled it to a database and network.
There is no chance of lifting out functionality to an interface in a sane manner.
Checked exceptions simply do not work with generalised concepts like interfaces.You don't have to make it that specific either, it was just an example. But if you're dealing with a file (for example), almost anything that can go wrong is an IOException of some kind, which is pretty sane to me. When it comes to services and interfaces, you usually have a custom top-level exception with a multitude of subexceptions. That way it stands on its own, and if anyone changes the interface and you don't recompile, you still catch the top-level exception, so everybody is happy.
-
@t_wheeler said:
(If you are replacing libraries without doing a rebuild, you are doing it WTF style and deserve whatever befalls you.)
So you create (and distribute) an application which depends on a number of third party (and system libraries). How are you going to make sure that all of the customers of your application are running a version that is compiled against the specific versions of the OS and tools (including service packs, hotfixes, et. al.) that exist on each of their machines. Are you going to distribute a new version every time a vendor of a library offers an update? Are you going to handle all of the permutations?
-
@TheCPUWizard said:
@t_wheeler said:
(If you are replacing libraries without doing a rebuild, you are doing it WTF style and deserve whatever befalls you.)
So you create (and distribute) an application which depends on a number of third party (and system libraries). How are you going to make sure that all of the customers of your application are running a version that is compiled against the specific versions of the OS and tools (including service packs, hotfixes, et. al.) that exist on each of their machines. Are you going to distribute a new version every time a vendor of a library offers an update? Are you going to handle all of the permutations?Sure, stuff changes and users do unexpected things. I don't see how this is an argument against checked exceptions. Your argument seems to be that checked exceptions give you a false sense of security about what your code handles. As opposed to the nice soothing blanket of ignorance that most developers would have without the checked exceptions?
Are you really saying that it's better to allow everyone to ignore these things than to have some developers take the easy way out and incorrectly swallow an exception? Should we all turn off compiler warnings and ignore the output of static code analysis, too?
-
@Salamander said:
Interesting how you see it as a benefit of checked exceptions - I see it as a detriment; By explicitly stating that printPaycheck throws a Database / Network exception, you've just tightly coupled it to a database and network.
There is no chance of lifting out functionality to an interface in a sane manner.
Checked exceptions simply do not work with generalised concepts like interfaces.That's the wrong way to handle exception propagation. If you have a high-level business method throwing low-level exceptions, you're mixing abstraction layers.
The proper way to handle exception propagation (in most cases) is to catch low-level exceptions, log a useful error message, and wrap the exception in a new exception that's at the proper level of abstraction. Possibly including enough information in the wrapping exception to let the code that will handle it do something more useful than let the user know Bad Stuff Happened.
Thomas
-
@TheCPUWizard said:
@t_wheeler said:
(If you are replacing libraries without doing a rebuild, you are doing it WTF style and deserve whatever befalls you.)
So you create (and distribute) an application which depends on a number of third party (and system libraries). How are you going to make sure that all of the customers of your application are running a version that is compiled against the specific versions of the OS and tools (including service packs, hotfixes, et. al.) that exist on each of their machines. Are you going to distribute a new version every time a vendor of a library offers an update? Are you going to handle all of the permutations?
First, if it's that important, the business (should!) have an SLA detailing which versions of the OS, libraries, etc. are required/supported. When they upgrade libg++ and the application craps all over the floor, you point them at the SLA and tell them they're on their own if they want to go down this road.
Beyond that, your argument essentially is that exceptions (and by extension, error handling) is a waste of time because the user can do something that will cause the application to break. I'd like to know what you propose to do instead.
Thomas
-
@boomzilla said:
@TheCPUWizard said:
@t_wheeler said:
(If you are replacing libraries without doing a rebuild, you are doing it WTF style and deserve whatever befalls you.)
So you create (and distribute) an application which depends on a number of third party (and system libraries). How are you going to make sure that all of the customers of your application are running a version that is compiled against the specific versions of the OS and tools (including service packs, hotfixes, et. al.) that exist on each of their machines. Are you going to distribute a new version every time a vendor of a library offers an update? Are you going to handle all of the permutations?Sure, stuff changes and users do unexpected things. I don't see how this is an argument against checked exceptions. Your argument seems to be that checked exceptions give you a false sense of security about what your code handles. As opposed to the nice soothing blanket of ignorance that most developers would have without the checked exceptions?
Are you really saying that it's better to allow everyone to ignore these things than to have some developers take the easy way out and incorrectly swallow an exception? Should we all turn off compiler warnings and ignore the output of static code analysis, too?
A false sense of security is exactly what I am talking about, and I have seen far too many real world situations to dismiss it. IMPO, the *only* way to deal with the situation is to do careful design work, and (in response to another reply) do through testing. I wonder how often other people do testing that involves exception injection and testing the responses of the calling code...
-
@t_wheeler said:
Beyond that, your argument essentially is that exceptions (and by extension, error handling) is a waste of time because the user can do something that will cause the application to break. I'd like to know what you propose to do instead.
Not be an asshole to customers? "We need to upgrade XYZ because it has a security vulnerability, but if we do that it breaks your application!" "Tough shit, you gotta recompile. What, you can't because you're not an awesome shit programmer like me? HAHAHAHAHA!"
I think the whole idea behind checked exceptions is flawed. Exceptions are supposed to be exceptional. By declaring your exceptions, you are lessening their exceptional status. Additionally, you are possibly leaking internal abstractions that don't matter to the caller. Finally, as mentioned earlier, you are encouraging people to write generic Exception handlers that swallow all exceptions just to shut the compiler up.
@t_wheeler said:
I don't know your background, but I can tell you that tearing the application down "immediately and rudely" is pretty much 100% not the right thing to do with any GUI-based application or server/service based application. Maybe you are in a different neck of the woods where that's the expected behavior.
Incidentally, I wanted to address this. There are really two kinds of exceptions: Ones that indicate an exceptional, but possibly expected, scenario where the current process can no longer run. For example, the network dropping. It sucks, but you can assume that any IO calls might fail, so whatever. These should not bring down the app.
The other kind of exception are more insidious. They are unexpected exceptions that manifest because of bugs or similar issues. NullPointerException? Odds are, you didn't dereference null explicitly. Probably, it's not supposed to be null. Why is it null? Is it a bug in your code? Is it memory corruption? Who knows, until you debug it! These indicate that your assumptions about your execution environment are not consistent with your actual environment. Continuing to execute in such a state is dangerous, and might indicate data corruption. You want to crash, not eat the exception and move on.
Sure, your users might not like it, but I'm sure they'd rather it crash than their data slowly be corrupted.
-
@TheCPUWizard said:
A false sense of security is exactly what I am talking about, and I have seen far too many real world situations to dismiss it. IMPO, the only way to deal with the situation is to do careful design work, and (in response to another reply) do through testing. I wonder how often other people do testing that involves exception injection and testing the responses of the calling code...
Yes, sure, but I don't see how any of this argues against checked exceptions. It's like saying there shouldn't be a fasten seat belt alarm in your car, because you should also make sure your brake line isn't cut.
-
I think the whole idea behind checked exceptions is flawed. Exceptions are supposed to be exceptional. By declaring your exceptions, you are lessening their exceptional status. Additionally, you are possibly leaking internal abstractions that don't matter to the caller. Finally, as mentioned earlier, you are encouraging people to write generic Exception handlers that swallow all exceptions just to shut the compiler up.
So we shouldn't have checked exceptions because programmers are lazy? Brilliant argument.
Yes, there are two kinds of exception. One is the programmer's fault. He passed null into a method, walked off the end of an array, whatever. This is an appropriate place for unchecked exceptions. The program should fail. The other kind of exception is something that can reasonably be expected to occur when it's run by a user/customer. Declaring these kinds of exceptions makes them part of the contract between caller and callee. When I call a method, I expect that method call to succeed and do something useful. That's part of the contract that method fulfills. I also expect to know what kinds of Bad Stuff can happen when that method is called. That's part of design by contract, which lets me handle both the expected and the unexpected cases. Declaring exceptions doesn't "lessen" their exceptional status. It makes them explicit, and actually increases the opportunities to handle them appropriately.
Thomas
-
@t_wheeler said:
So how do programmers manage to get this done with languages that don't have checked exceptions?Declaring these kinds of exceptions makes them part of the contract between caller and callee. When I call a method, I expect that method call to succeed and do something useful. That's part of the contract that method fulfills. I also expect to know what kinds of Bad Stuff can happen when that method is called. That's part of design by contract, which lets me handle both the expected and the unexpected cases. Declaring exceptions doesn't "lessen" their exceptional status. It makes them explicit, and actually increases the opportunities to handle them appropriately.
-
@t_wheeler said:
So we shouldn't have checked exceptions because programmers are lazy? Brilliant argument.
I won't comment on checked exceptions, but if the feature doesn't work with real programmers here in reality, then it's a bad feature.
You might dislike that programmers are lazy, but the simple fact of the matter is that a lot of programmers arelazy. So if your language can be rejiggered to better support lazy programmers, it should be.
Of course this whole conversation is moot, since Java is dead.
-
@blakeyrat said:
@t_wheeler said:
So we shouldn't have checked exceptions because programmers are lazy? Brilliant argument.
I won't comment on checked exceptions, but if the feature doesn't work with real programmers here in reality, then it's a bad feature.
You might dislike that programmers are lazy, but the simple fact of the matter is that a lot of programmers arelazy. So if your language can be rejiggered to better support lazy programmers, it should be.
Of course this whole conversation is moot, since Java is dead.
Dead, but hardly unused.
-
@pkmnfrk said:
Dead, but hardly unused.
My point is that there's no point in musing about possible improvements to the language since it'll never be improved.
-
@blakeyrat said:
@t_wheeler said:
So we shouldn't have checked exceptions because programmers are lazy? Brilliant argument.
I won't comment on checked exceptions, but if the feature doesn't work with real programmers here in reality, then it's a bad feature.
You might dislike that programmers are lazy, but the simple fact of the matter is that a lot of programmers arelazy. So if your language can be rejiggered to better support lazy programmers, it should be.
Of course this whole conversation is moot, since Java is dead.
Lazy programmers produce crap code no matter the language they're working in. In C# I see generic catch clauses everywhere, just like I do in Java. In C++ I saw error codes ignored and code that threw all kinds of objects (C++ lets you throw anything as an exception). Designing languages to coddle the lazy programmer is as much a waste of time as trying to design a "foolproof" system.
However, languages should make it as easy as possible to do things the right way (in terms of good design/architecture).
Off-topic but I've wanted to ask you -- which languages do you consider to be "alive" and what are your criteria for determining alive-ness?
Thomas
-
@t_wheeler said:
Lazy programmers produce crap code no matter the language they're working in.
Ok, so let's work to reduce that crap code by making it easier for lazy programmers to use the language. That doesn't really address what I said.
@t_wheeler said:
Designing languages to coddle the lazy programmer is as much a waste of time as trying to design a "foolproof" system.
Nobody's saying you design the language to "coddle the lazy programmer". Look, if feature A is demonstrably hard-to-use, and demonstrably frequently mis-used, then it should be fixed. Regardless of what the programmer's intention or level of motivation is.
@t_wheeler said:
Off-topic but I've wanted to ask you -- which languages do you consider to be "alive" and what are your criteria for determining alive-ness?
I don't have any hard-and-fast rules.
-
@t_wheeler said:
It's interesting that the most prominent language with mandatory checked exceptions is one of the worst at making it easy to do things the right way.However, languages should make it as easy as possible to do things the right way (in terms of good design/architecture).
-
@blakeyrat said:
@t_wheeler said:
Lazy programmers produce crap code no matter the language they're working in.
Ok, so let's work to reduce that crap code by making it easier for lazy programmers to use the language. That doesn't really address what I said.@t_wheeler said:
Designing languages to coddle the lazy programmer is as much a waste of time as trying to design a "foolproof" system.
Nobody's saying you design the language to "coddle the lazy programmer". Look, if feature A is demonstrably hard-to-use, and demonstrably frequently mis-used, then it should be fixed. Regardless of what the programmer's intention or level of motivation is.Okay, I think "lazy programmers" and "hard-to-use features" and "frequently misused" is three different problem cases although there's probably a tangential relationship between all three. I think the solution for the problem of lazy programmers is for us to be more disciplined and to use tools that force us to be less lazy. The solution for hard-to-use features is to simplify/redesign them. The frequently misused category seems to me to be the area where exception handling fits. I don't think exception handling is hard to use; but it certainly is prone to misuse (and abuse). Regardless of whether it's checked or unchecked exceptions, or just plain old "return -1" error codes.
I think part of the reason for this is we tend not to think about the exceptional conditions when we're writing code. We're busy trying to get the happy path working, and thinking about all the problems that can crop up is an extra mental load that we can't handle. (Or at least, don't want to.) So we do the simplest thing possible to deal with errors. A related point is when the compiler (or IDE) complains about an exception not being handled, we just want to get rid of the error and move on with our train of thought -- which leads to the catch-and-log and catch-and-ignore anti-patterns so commonly seen.
Another issue is there doesn't seem to be much discussion about how to handle exceptional conditions. Consequently there is a lack of awareness and education.
Once I learned how to properly use checked exceptions I discovered that I was writing far fewer catch clauses, and my code's ability to deal with exceptional conditions improved remarkably. Many (perhaps even most) of my methods now just have a throws clause on them. Mid-level and upper-level methods catch exceptions and either (1) log and throw another exception at a higher abstraction level (wrapping the caught exception), or catch the exception and do something useful to handle the error that occurred.
@blakeyrat said:
@t_wheeler said:
Off-topic but I've wanted to ask you -- which languages do you consider to be "alive" and what are your criteria for determining alive-ness?
I don't have any hard-and-fast rules.
Okay. Can you give me a couple examples a non-dead language?
Thomas
-
@PedanticCurmudgeon said:
@t_wheeler said:
It's interesting that the most prominent language with mandatory checked exceptions is one of the worst at making it easy to do things the right way.However, languages should make it as easy as possible to do things the right way (in terms of good design/architecture).
Compared to other languages available back in the late 1990s, Java looked pretty good. Compared to a lot of modern languages Java is verbose, requires you to write a lot of boilerplate code, and lacks features. To some extent I think that makes it harder to do things the right way.
Thomas
-
Re: Checked Exceptions- one of the issues with it is that having it can often leak implementation details, and can be troublesome when used with interfaces as well as various inheritance structures, for example, an IOException from a method of a interface might not make sense in all cases, but might make sense for some implementations.
I would say one way that this is mitigated as a problem is not to declare a checked exception of those types on an interface, but instead wrap checked exceptions in a new Exception class type, and declare that in that methods throws clause- so a interface for something that retrieves some data might have implementations that read from a file or Memory (which would have IOExceptions) or from the internet (which has another exception type) and so forth. Instead of declaring a method as "throws IOException,WebException...etc" instead a new Exception class is created that wraps that type- eg. "DataReadingException" or something, depending on the routine being used. This makes sense (IMO) because a consumer of the interface won't know specifically what went wrong, but might have a codepath to follow if something does, and this is more specific than a generic catch clause that catches everything, too.
On the other hand, Exceptions are, as their name implies, for Exceptional conditions and we should be writing code to try to prevent them from happening in the first place- that is, take a proactive rather than reactive approach; Don't handle the exception where a file is not found, instead make sure the file exists before trying to call the method that would throw that Exception, etc. The Java approach seems to go with the idea that the Exceptions in some sense drive the program logic enough to have them declared as part of the method header.
I think the C# designers went with the approach that while they saw a few issues with Java's Checked Exceptions, but they didn't have a good way to 'fix' it at the time, so they left it "open" so they could go back and add something that made sense later. Some could even argue that the contracts framework (like spec#) help solve some of the issues regarding metadata documentation.
-
@t_wheeler said:
think the solution for the problem of lazy programmers is [...] to use tools that force us to be less lazy. [..] The solution for hard-to-use features is to simplify/redesign them.
I feel there are two kinds of hard to use features. One is the poorly designed feature that should be easy to use because it's a verycommon error-prone thing and computer features exist explicitly to make our lives easier. So easy things should be easy. Common things should be easy. Hard but common things should be easy. Impossible things should be hard.
But, some things are just hard. No way around them. Quantum mechanics can be explained to a layman in a few paragraphs, but that layman isn't going to do the real work! And if you want to do the real work with a deep understanding of the material, some things are just hard.
Unfortunately, I've never written any Java, so I can't say in which hardness-category Java's checked exceptions fall.
@t_wheeler said:
We're busy trying to get the happy path working
This is true; at least for me.
@t_wheeler said:
Many (perhaps even most) of my methods now just have a throws clause on them.
A lot of the time, the separation between my code and a user is very small, so I write very, very few try/catch constructions. My philosophy is that invalid input from the user isn't an exception— it's an expection. Just validate the input, output a friendly message and don't process further.
Invalid input from a programmer using my utility API is a different matter (even if it's only me, calling my own library code). But I realized during writing this post that I've been inconistent in the past and should think about the issue more.
@t_wheeler said:
Thomas
You've presented yourself so far as a lucid person. Don't break that illusion with constant redundant post-signing. ;)
-
@BC_Programmer said:
Don't handle the exception where a file is not found, instead make sure the file exists before trying to call the method that would throw that Exception, etc.
You just have to make sure you handle race conditions. So make sure that you check for the file, like, a few times in a loop to make sure.
I would say that while checked exceptions can help make developers more proactive, they sometimes contribute to anti-patterns (but then what doesn't?). And there's no accounting for taste. This feels like yet another a static vs dynamic language religious conflict.
-
@BC_Programmer said:
Re: Checked Exceptions- one of the issues with it is that having it can often leak implementation details
But why is it a problem? At what point do we lose time or insight or mental health? Or do we lose something else?
@BC_Programmer said:
I would say one way that this is mitigated as a problem is not to declare a checked exception of those types on an interface, but instead wrap checked exceptions in a new Exception class type, and declare that in that methods throws clause
I can't envision another way of doing it. I wrote a three-layer app in ASP classic (wooo!) and pretty much did exactly this, except with custom objects instead of error objects. You don't want an upper layer to ever go, What the fuck do I do with this?! when it's receiving an error from more than 1 layer down.
@BC_Programmer said:
On the other hand, Exceptions are, as their name implies, for Exceptional conditions and we should be writing code to try to prevent them from happening in the first place
Exceptions exist to formalize and control when and how your program breaks. This whole expected/unexpected duality is a misnomer to me. Invalid user input is completely expected to occur all the time. Should it be treated as an exceptional condition or part of the happy path? Malformed data, on the other hand, is completely unexpected, because you expect the technology to work correctly; you expect the programmer to RTFM.
The basic issue is that programs bomb and fall down on their face. You don't want this. You want to step in and lovingly catch the fumbling software in your strong, capable, soothing arms. try/catch Exceptions, checked or not, are just an explicit system to enable you to do so. Every design choice should boil down to "do not explode".
-
@dhromed said:
@BC_Programmer said:
Re: Checked Exceptions- one of the issues with it is that having it can often leak implementation details
But why is it a problem? At what point do we lose time or insight or mental health? Or do we lose something else?
never said it was a problem, but some people take issue with that. You know, OO purists. Actually now that I think of it this could be considered a good thing. Hell I'd go out of my way to piss off a devout OO purist.
@dhromed said:
@BC_Programmer said:
I would say one way that this is mitigated as a problem is not to declare a checked exception of those types on an interface, but instead wrap checked exceptions in a new Exception class type, and declare that in that methods throws clause
I can't envision another way of doing it. I wrote a three-layer app in ASP classic (wooo!) and pretty much did exactly this, except with custom objects instead of error objects. You don't want an upper layer to ever go, What the fuck do I do with this?! when it's receiving an error from more than 1 layer down.
Exactly- so we have to ask what exactly the checked Exception model is really giving us- or, more precisely, the "optional" checked Exceptions that Java provides. One thing that it does give you is extra data about the Exceptions a method throws- or, rather, the more important exceptions it throws.
I think a lot of the negatives towards the model might be based on people not using it properly, or, more likely, having to use code that doesn't use it properly, such as methods that either declare that they "throws Exception" or list Exceptions in their throws clause for which the calling code couldn't possibly know what the fuck to do.
@dhromed said:
@BC_Programmer said:
On the other hand, Exceptions are, as their name implies, for Exceptional conditions and we should be writing code to try to prevent them from happening in the first place
Exceptions exist to formalize and control when and how your program breaks. This whole expected/unexpected duality is a misnomer to me. Invalid user input is completely expected to occur all the time. Should it be treated as an exceptional condition or part of the happy path? Malformed data, on the other hand, is completely unexpected, because you expect the technology to work correctly; you expect the programmer to RTFM.
I agree that user input is expected to be malformed. That's also why I think anything throwing Exceptions as a result of that as rather dumb. eg. the Parse() static methods of the .NET primitive types throwing Exception; basically those Exceptions are badly designed, because they are essentially being used as a sort of return value. (for the case where the value cannot be parsed, that is).
The basic issue is that programs bomb and fall down on their face. You don't want this. You want to step in and lovingly catch the fumbling software in your strong, capable, soothing arms. try/catch Exceptions, checked or not, are just an explicit system to enable you to do so. Every design choice should boil down to "do not explode".
Agree.
You just have to make sure you handle race conditions. So make sure that you check for the file, like, a few times in a loop to make sure.
Good point; obviously, such a check would not itself replace the use of an Exception handler, but would supplement it- that is, to try to avoid the exception being thrown as best as possible.
I would say that while checked exceptions can help make developers more proactive, they sometimes contribute to anti-patterns (but then what doesn't?). And there's no accounting for taste. This feels like yet another a static vs dynamic language religious conflict.
Have to agree. I'd say there are good arguments both for and against the use of checked Exceptions at a language level. A lot of polarization might be as a result of the languages a person uses the most; Java Programmers are more likely to expunge the benefits of Checked Exceptions (or the issues of not having them), whereas C# Programmers are more likely to talk about their problems (or the virtues of not having them). (Which is pretty much analogous to the case for static and dynamic languages)
-
@BC_Programmer said:
@dhromed said:
@BC_Programmer said:
Re: Checked Exceptions- one of the issues with it is that having it can often leak implementation details
But why is it a problem? At what point do we lose time or insight or mental health? Or do we lose something else?
never said it was a problem, but some people take issue with that. You know, OO purists. Actually now that I think of it this could be considered a good thing. Hell I'd go out of my way to piss off a devout OO purist.
I think we would all probably agree that leaking implementation details is a bad thing. But you haven't connected the concept of checked exceptions to leaking implementation details. If anything, the checked exceptions are a nudge to the developer to handle them before the leak, no?
Lazy programmers without checked exceptions are probably more likely to let those inappropriate level of abstraction exceptions bubble up than lazy programmers with checked exceptions. I think the obvious answer is for everyone to just stop programming.
-
@boomzilla said:
I think the obvious answer is for everyone to just stop programming.
QFT.
I'm late for my Diablo III goldloot farming appointment.
-
@t_wheeler said:
Because everyone knows the only alternatives that existed back then were VB and c++.Compared to other languages available back in the late 1990s, Java looked pretty good.
-
@BC_Programmer said:
You just have to make sure you handle race conditions. So make sure that
Good point; obviously, such a check would not itself replace the use of an Exception handler, but would supplement it- that is, to try to avoid the exception being thrown as best as possible.
you check for the file, like, a few times in a loop to make sure.Is BC_Programmer wooshed, or am I wooshed? The joke is that a file can literally disappear at any millisecond completely beyond your program's control, when you're opening a file on disk you have to handle the exception in an intelligent way. The joke is that checking if the file exists won't guarantee the file exists when you actually try to open it. Checking if the file exists in a loop won't make it more likely the file exists when you open it, it just wastes time.
Anyway.
-
@BC_Programmer said:
I would say one way that this is mitigated as a problem is not to declare a checked exception of those types on an interface, but instead wrap checked exceptions in a new Exception class type, and declare that in that methods throws clause- so a interface for something that retrieves some data might have implementations that read from a file or Memory (which would have IOExceptions) or from the internet (which has another exception type) and so forth. Instead of declaring a method as "throws IOException,WebException...etc" instead a new Exception class is created that wraps that type- eg. "DataReadingException" or something, depending on the routine being used. This makes sense (IMO) because a consumer of the interface won't know specifically what went wrong, but might have a codepath to follow if something does, and this is more specific than a generic catch clause that catches everything, too.
We have a winner! Yes -- if your interface method is throwing IOException, WebException, SQLException, you are almost certainly exposing internal implementation details and should replace that with an exception at a higher level of abstraction. (I said this earlier in the thread, but maybe you didn't see it -- don't blame you, it's a pretty long thread at this point.)
@BC_Programmer said:
On the other hand, Exceptions are, as their name implies, for Exceptional conditions and we should be writing code to try to prevent them from happening in the first place- that is, take a proactive rather than reactive approach; Don't handle the exception where a file is not found, instead make sure the file exists before trying to call the method that would throw that Exception, etc. The Java approach seems to go with the idea that the Exceptions in some sense drive the program logic enough to have them declared as part of the method header.
This is why in Java there are two kinds of exceptions. Unchecked exceptions are the programmer's fault and indicate faulty logic. They are not declared because they are not part of the contract of the method. (Would you really like to see a "throws NullPointerException, IllegalArgumentException, NoClassDefFoundException" on a majority of your code? Didn't think so :).) Checked exceptions indicate things that can be expected to go wrong during normal execution of the method. As such they are part of the contract of the method, and just as an important and valuable part of its signature as its name, parameter types, and return type. So when I see "depositPaycheck() throws BankingServiceException, AccountException" I know that as part of its contract, depositPaycheck() is allowed to fail and there are two ways in which it can legally fail.
And yes, we should take steps to try to prevent exceptions from occurring -- but all the code in the world isn't going to help you if a rat gnawed through the network cable. Or somebody logged in as root runs "rm -rf /tmp" and deletes our working files.
@dhromed said:
So easy things should be easy. Common things should be easy. Hard but common things should be easy. Impossible things should be hard.
You missed (at least) one case. How about hard but uncommon things? And since impossible things should only be "hard", can I expect from a design for a perpetual motion machine soon? :-)
Redundantly,
Thomas
-
@t_wheeler said:
You missed (at least) one case. How about hard but uncommon things? And since impossible things should only be "hard", can I expect from a design for a perpetual motion machine soon? :-)
It's just an expression.
@t_wheeler said:
Redundantly,
oh it's on
-
@t_wheeler said:
Here's why I like checked exceptions. [...] Without checked exceptions, I'm going to end up with something like:
try { payrollSystem.printPaycheck(emp);
} catch(Exception e) {
// show a dialog box indicating things went wrong
}Why? Because I have no idea what exceptions are being thrown by printPaycheck() and no way to find out. But if I have checked exceptions I can do something more user-friendly:
try { payrollSystem.printPaycheck(emp);
} catch(DatabaseException e) {
// let the user know the database appears to be offline and they should try again later
} catch(NetworkException e) {
// let the user know there was an issue connecting to the network
} catch(PrintException) {
// let the user know there was a problem printing, maybe the printer is offline or needs paper?
}And this has to do with checked exceptions.. what? You're confusing typed exceptions with checked exceptions. You can perfectly do typed catches in environments that don't support checked exceptions.
In addition, what you are doing here is wrong. You should not have caught those exceptions at all at that point if all you do is reporting errors. Reporting errors should only be done on the top level (entry point) and not at the code point that calls printPayCheck. At the top level, the system will know whether there is a user at all (instead of a deaf service call) and how to report (log? web page? message box?), That is something your coded point does not know. The top level also knows from the stack trace where the error occurred (print paycheck). One top level handler can handle all method invocations: printInvoice, shipOrder,...
-
@blakeyrat said:
The joke is that checking if the file exists won't guarantee the file exists when you actually try to open it.
Similarly, checking the file exists doesn't guarantee that you are able to open it (no read/change permission), simply that you can "see" the object at that point in time.
-
