4 ms·

Relying on the IDE to know which exceptions can be thrown is nicer I think. The .NET pattern of inner exceptions is nice too (relevant to the article's example

Relying on the IDE to know which exceptions can be thrown is nicer I think. The .NET pattern of inner exceptions is nice too (relevant to the article's example, you could throw an NHibernateException(inner exception:SQLForeignKeyViolatedException)). It's nice I guess from a certainty and stability standpoint in Java to know that you won't have an exception crash your system, but even then you aren't going to be sure because some exceptions do crash your system because they aren't checked (e.g. null pointer, array index etc.). In my opinion Java is a dead language anyway. The language's bloat (exceesive boiler-plate required for everything), lack of high-level functionality and general approach to boxing in the programmer mean that new programmers don't want to use it (most will learn it though). The slow initialisation time (JVM problem) and lack of native interfaces (despite the work done here) mean that companies don't want to use it for customer products. For internal apps, I'd wager that the company just wants something that most people know and that is quick to develop in, and while Java has some ground here I think other languages will be making strong headway too, especially when you have some control on the deployment platforms. Java just strikes me as dissapointing now. It is probably single-handedly responsible for us getting over the fear of automatic memory management and GC. Similarly it's had massive influences on virtual machines and easy cross-platform deployment. Just about every CS student in the world knows Java. But right now it has failed to innovate with the resurgent popularity for language functionality, address the issue of bloat or develop on the issues that discourage people actually using it for cross-platform deployment. In the mobile sector it's pretty strong, but Objective-C/iPhone will probably hurt that, and it's only strong because of the JVM's portability. On the web it had the potential to take out flash, but the incredible load time and associated lag of the JVM initialising has killed that chance. Overall, Java is only afloat because it is too big to sink.

swolchok 17y ago
Relying on the IDE to know which exceptions can be thrown is nicer I think. No. If you can't remember what it throws, you can't remember the documentation. If you can't remember the documentation, you don't fully know how to use it properly. Go read the documentation; IDEs are a crutch. EDIT: I'm completely serious. http://docs.python.org/library/ http://docs.python.org/library/ and help() are my best friends, in that order.
- nopassrecover 17y ago
  I think knowing every exception a method can throw and knowing the method are different things. I want to be able to write code, while I'm in the zone and thinking about the business problem, not have to jump and navigate a web site for every method call. And I didn't say you can't check the domentation from the IDE (through a nice context link) but I still think mouseover on a method that lists exceptions (as Visual Studio does) is the ideal solution as it gives me the information I need as I code. NB: VS exception info is comment documentation based, I have no idea why the compiler doesn't generate this information as much as possible becuase then you are getting some of the advantage of checked exceptions without the cost. As a counterpoint to knowing the documentation, consider the System.Reflection.MethodBase.Invoke method in .NET which I have in front of me, are you going to remember all these exceptions: // Exceptions: // System.Reflection.TargetException: // The obj parameter is null and the method is not static. -or- The method // is not declared or inherited by the class of obj. -or- A static constructor // is invoked, and obj is neither null nor an instance of the class that declared // the constructor. // // System.ArgumentException: // The elements of the parameters array do not match the signature of the method // or constructor reflected by this instance. // // System.Reflection.TargetInvocationException: // The invoked method or constructor throws an exception. // // System.Reflection.TargetParameterCountException: // The parameters array does not have the correct number of arguments. // // System.MethodAccessException: // The caller does not have permission to execute the constructor. // // System.InvalidOperationException: // The type that declares the method is an open generic type. That is, the System.Type.ContainsGenericParameters // property returns true for the declaring type.
  - swolchok 17y ago
    I didn't say you have to know the documentation, and I'll admit I'm behind on how much of it IDEs show you. In my recollection, you generally get a list of language-level constructs and that's it. For example, the names of those exceptions are not as useful as the text you've shown there. If VS does that for exceptions, great! Contrast it with the 2003/2005 IntelliSense feature, where you just get method prototypes.
kevinpet 17y ago
Java the language will soon be replacing COBOL as the boring legacy language of choice. Java the virtual machine is alive and well and I suspect will have a long life.

swolchok 17y ago

Relying on the IDE to know which exceptions can be thrown is nicer I think. No. If you can't remember what it throws, you can't remember the documentation. If you can't remember the documentation, you don't fully know how to use it properly. Go read the documentation; IDEs are a crutch. EDIT: I'm completely serious. http://docs.python.org/library/ http://docs.python.org/library/ and help() are my best friends, in that order.

nopassrecover 17y ago
I think knowing every exception a method can throw and knowing the method are different things. I want to be able to write code, while I'm in the zone and thinking about the business problem, not have to jump and navigate a web site for every method call. And I didn't say you can't check the domentation from the IDE (through a nice context link) but I still think mouseover on a method that lists exceptions (as Visual Studio does) is the ideal solution as it gives me the information I need as I code. NB: VS exception info is comment documentation based, I have no idea why the compiler doesn't generate this information as much as possible becuase then you are getting some of the advantage of checked exceptions without the cost. As a counterpoint to knowing the documentation, consider the System.Reflection.MethodBase.Invoke method in .NET which I have in front of me, are you going to remember all these exceptions: // Exceptions: // System.Reflection.TargetException: // The obj parameter is null and the method is not static. -or- The method // is not declared or inherited by the class of obj. -or- A static constructor // is invoked, and obj is neither null nor an instance of the class that declared // the constructor. // // System.ArgumentException: // The elements of the parameters array do not match the signature of the method // or constructor reflected by this instance. // // System.Reflection.TargetInvocationException: // The invoked method or constructor throws an exception. // // System.Reflection.TargetParameterCountException: // The parameters array does not have the correct number of arguments. // // System.MethodAccessException: // The caller does not have permission to execute the constructor. // // System.InvalidOperationException: // The type that declares the method is an open generic type. That is, the System.Type.ContainsGenericParameters // property returns true for the declaring type.
- swolchok 17y ago
  I didn't say you have to know the documentation, and I'll admit I'm behind on how much of it IDEs show you. In my recollection, you generally get a list of language-level constructs and that's it. For example, the names of those exceptions are not as useful as the text you've shown there. If VS does that for exceptions, great! Contrast it with the 2003/2005 IntelliSense feature, where you just get method prototypes.

kevinpet 17y ago

Java the language will soon be replacing COBOL as the boring legacy language of choice. Java the virtual machine is alive and well and I suspect will have a long life.