StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
11977189
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
5
CommunityOwnedDate
CreationDate
2012-08-15T20:59:21.843
FavoriteCount
0
LastActivityDate
2014-01-19T04:14:16.747
LastEditDate
2014-01-19T04:14:16.747
LastEditorUserId
1569108
OwnerUserId
1569108
ParentId
2444633
PostTypeId
2
Score
4
ViewCount
0
LastEditorDisplayName
text
Body
You can still use generic methods, like this: <pre><code>public class SomeException { private final Object target; public SomeException(Object target) { this.target = target; } public <T> T getTarget() { return (T) target; } } .... catch (SomeException e) { Integer target = e.getTarget(); } </code></pre> I do agree with Cristian's answer above. While the accepted answer is technically correct (insofar as it references the JVM specs), Cristian Vasile's answer is one that qualifies and even challenges the limitation. There are least two arguments that I noted in answers to this question that I do not agree with and that I will rebut. If the arguments in these answers were correct, we could use these arguments to attack generics in other contexts where they are used successfully today. <hr> The first argument states that we can't use this: <pre><code>catch (Exception<T1> e) {} </code></pre> because the JVM doesn't know how to work with <code>Exception<T1></code>. This argument would seem to also attack this use of generics, on the basis that the JVM doesn't know how to use <code>List<T1></code>: <pre><code>List<T1> list; </code></pre> The argument, of course, forgets that the compiler performs type erasure and so the JVM doesn't need to know how to handle <code>Exception<T1></code>. It can simply handle <code>Exception</code>, just like it handles <code>List</code>. Of course, we could never handle <code>catch(Exception<T1> e)</code> and <code>catch(Exception<T2> e)</code> in the same try/catch because of type erasure, but then again, that's no worse than with method arguments or return values today: we don't handle <code>myMethod(List<T1>)</code> and <code>myMethod(List<T2>)</code> today either... (I reiterate this aspect in the second rebuttal below.) <hr> A second argument goes as follows. We don't allow this: <pre><code>catch (Exception<T1> e) {} </code></pre> because this wouldn't work: <pre><code>catch (Exception<T1> e) {} catch (Exception<T2> e) {} </code></pre> OK, then why not disallow this: <pre><code>interface MyInterface { Comparable<Integer> getComparable(); } </code></pre> because this does not work: <pre><code>interface MyInterface { Comparable<Integer> getComparable(); Comparable<String> getComparable(); } </code></pre> or this: <pre><code>interface MyInterface { void setComparable(Comparable<Integer> comparable); } </code></pre> because this does not work: <pre><code>interface MyInterface { void setComparable(Comparable<Integer> comparable); void setComparable(Comparable<String> comparable); } </code></pre> In other words, why not disallow generics in most cases? This second argument forgets that, although we couldn't possibly allow different generic constructs that that erase to the same non-generic construct in these contexts, we can still do the next best thing and allow generics as long as the types don't erase to the same type. That's what we do with method parameters: we allow you to use generics, but complain as soon as we detect duplicate signatures after type erasure. Well, we could have done about the same thing with exceptions and catch blocks... <hr> In conclusion, I would expand on Cristian's answer. Instead of allowing generic exception classes and using the raw types in <code>catch</code> blocks: <pre><code>class MyException<T> {} ... catch (MyException e) { // raw </code></pre> Java could have gone the whole way without problems: <pre><code>class MyException<T> {} ... catch (MyException<Foo> e) { </code></pre>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhy doesn't Java support generic Throwables?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USMihai Danila
UserOwnerUserId
1. USMihai Danila
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COSome of my examples may appear confusing. When I give the two examples of method signatures that erase to the same signature, I refer to real examples if invalid situations that compliant compilers must refuse to compile. I merely point out that these situations (erasure to the same generic type) were not used by the language designers as a premise to ban generics across the board, but they seem to have been used to ban generics in throws clauses. Instead, the compiler was made to recognize and report such cases. It could have done the same for catch clauses. The choice seems arbitrary.
 singulars
 PostPostId
 PO
 UserUserId
 USMihai Danila

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.