b******y
发帖数: 1684 | 1 for functions like this:
List search(...) {
}
When the search can't get anything, would you return null, or empty list? |
Z****e
发帖数: 2999 | 2 I prefer empty list
【在 b******y 的大作中提到】
: for functions like this:
: List search(...) {
: }
: When the search can't get anything, would you return null, or empty list?
|
A**o
发帖数: 1550 | 3 empty list is easier for caller to handle. but it's hard to enforce because
many frameworks don't have such convention, and in the end, you still want
to check for NPE or risk NPE showing up in front of customer.
so, it's a nice to have convention. |
b******y
发帖数: 1684 | 4 speaking of convention, 你的函数的开头都validate arguments吗？
照说public method要throw IllegalArgumentExecption,
private method要用assert，然否？
because
【在 A**o 的大作中提到】
: empty list is easier for caller to handle. but it's hard to enforce because
: many frameworks don't have such convention, and in the end, you still want
: to check for NPE or risk NPE showing up in front of customer.
: so, it's a nice to have convention.
|
A**o
发帖数: 1550 | 5 in an ideal world. but with refactor tools so strong,
private and public functions transform back and forth no stop,
not much you can do about these. a good test case coverage may serve better,
again, ideally.
【在 b******y 的大作中提到】
: speaking of convention, 你的函数的开头都validate arguments吗？
: 照说public method要throw IllegalArgumentExecption,
: private method要用assert，然否？
:
: because
|
b******y
发帖数: 1684 | 6 what refactor tools u use?
better,
【在 A**o 的大作中提到】
: in an ideal world. but with refactor tools so strong,
: private and public functions transform back and forth no stop,
: not much you can do about these. a good test case coverage may serve better,
: again, ideally.
|
A**o
发帖数: 1550 | 7 just intellij
【在 b******y 的大作中提到】
: what refactor tools u use?
:
: better,
|
b******y
发帖数: 1684 | 8 o... we use eclipse...
back to that illegalargumentexception Q, it can catch exception
real time, while test case can't necessarily reproduce the situation.
what's the disadvantage of having methods validate their arguments
and throw illegalargumentexception? make system slower?
【在 A**o 的大作中提到】
: just intellij
|
A**o
发帖数: 1550 | 9 it's a good practice if you can enforce it and standardlize it
w/o hurting your developer's morale and speed. that's all.
【在 b******y 的大作中提到】
: o... we use eclipse...
: back to that illegalargumentexception Q, it can catch exception
: real time, while test case can't necessarily reproduce the situation.
: what's the disadvantage of having methods validate their arguments
: and throw illegalargumentexception? make system slower?
|
F****n
发帖数: 3271 | 10 Unfortunately, yes performance could be a big issue.
【在 b******y 的大作中提到】
: o... we use eclipse...
: back to that illegalargumentexception Q, it can catch exception
: real time, while test case can't necessarily reproduce the situation.
: what's the disadvantage of having methods validate their arguments
: and throw illegalargumentexception? make system slower?
|
|
|
c*****t
发帖数: 1879 | 11 Since IDEs only generate catch statements for checked exceptions and
some programmers just don't handle (either dunno or lazy) unchecked
exceptions. So throwing this kind of exception can be quite dangerous.
Only usable within certain confined areas.
【在 b******y 的大作中提到】
: o... we use eclipse...
: back to that illegalargumentexception Q, it can catch exception
: real time, while test case can't necessarily reproduce the situation.
: what's the disadvantage of having methods validate their arguments
: and throw illegalargumentexception? make system slower?
|
b******y
发帖数: 1684 | 12 assume the validation logic is valid, then not doing it would
only make your system more vulnerable...
well, of cuz in most cases, even if the caller is not calling
the method with valid arguments, the system might still continue
w/o being broken. but in the cases where a call w/ invalid
arguments, not throwing illegalargumentexception here would
make it more difficult to diagnosis.
【在 c*****t 的大作中提到】
: Since IDEs only generate catch statements for checked exceptions and
: some programmers just don't handle (either dunno or lazy) unchecked
: exceptions. So throwing this kind of exception can be quite dangerous.
: Only usable within certain confined areas.
|
c*****t
发帖数: 1879 | 13 You misunderstood my position. I was arguing that throwing
IllegalArgumentException itself, or any other runtime exceptions
could be dangerous. For error checking, try to wrap it (and other
runtime errors) with checked exceptions.
【在 b******y 的大作中提到】
: assume the validation logic is valid, then not doing it would
: only make your system more vulnerable...
: well, of cuz in most cases, even if the caller is not calling
: the method with valid arguments, the system might still continue
: w/o being broken. but in the cases where a call w/ invalid
: arguments, not throwing illegalargumentexception here would
: make it more difficult to diagnosis.
|
s******n
发帖数: 876 | 14 that would be an abuse of checked exeptions.
【在 c*****t 的大作中提到】
: You misunderstood my position. I was arguing that throwing
: IllegalArgumentException itself, or any other runtime exceptions
: could be dangerous. For error checking, try to wrap it (and other
: runtime errors) with checked exceptions.
|
A**o
发帖数: 1550 | 15 i remember there was an arguement saying
the caught exceptions are evil. something like it.
so, i think it's a preference.
【在 c*****t 的大作中提到】
: You misunderstood my position. I was arguing that throwing
: IllegalArgumentException itself, or any other runtime exceptions
: could be dangerous. For error checking, try to wrap it (and other
: runtime errors) with checked exceptions.
|
c*****t
发帖数: 1879 | 16 The problem is this, which happens quite often in library codes.
Library A:
try
{
foo (); // through injection, calls user function
}
catch (AException ex) // auto generated by IDE
{
printStackTrace ();
}
catch (... ex)
...
This looks all good, except that it would break on all runtime
exceptions on minor things such as illegalArgumentException.
You can try to fix the library code yourself, but if the user
update the library (e.g. install the latest), code would break.
You can argue th
【在 A**o 的大作中提到】
: i remember there was an arguement saying
: the caught exceptions are evil. something like it.
: so, i think it's a preference.
|
A**o
发帖数: 1550 | 17 you have your arguement. the other side of the problem
being an exception is eation by a catch(Exception e) block
and behaving like everything is ok at the end of call
but in fact something was wrong under.
this happens a lot when you are dealing legacy codes.
and sometimes it also rooted to some careless ex-coder
who simply threw an Exception instance.
i've been in a project with 4k classes, and 7k references
of catch Exception blocks. //orz
【在 c*****t 的大作中提到】
: The problem is this, which happens quite often in library codes.
: Library A:
: try
: {
: foo (); // through injection, calls user function
: }
: catch (AException ex) // auto generated by IDE
: {
: printStackTrace ();
: }
|
b******y
发帖数: 1684 | 18 the leak comes from this user function...
why should the lib cover up for the user function?
in reality case, if not showing odd exception to end user is a concern,
you can add a catch (Exception ex) at the top level of presentation
tier, and wrap it up there.
【在 c*****t 的大作中提到】
: The problem is this, which happens quite often in library codes.
: Library A:
: try
: {
: foo (); // through injection, calls user function
: }
: catch (AException ex) // auto generated by IDE
: {
: printStackTrace ();
: }
|
m******t
发帖数: 2416 | 19 It doesn't just remind the caller, it _forces_ the caller
to deal with it when the caller may not want to or need to
or be able to.
Checked exception is a great way to remind the caller that, hey
check the error before moving on. IllegalArgumentException just
doesn't cut it since unless one is really looking for it, you
won't know there is a problem until things break.
【在 c*****t 的大作中提到】
: The problem is this, which happens quite often in library codes.
: Library A:
: try
: {
: foo (); // through injection, calls user function
: }
: catch (AException ex) // auto generated by IDE
: {
: printStackTrace ();
: }
|
g*****g
发帖数: 34805 | 20 I wouldn't mind using RuntimeException as long as the caller
cannot recover from it. Whenever I catch an exception, I would
always call logger.error("...", e) or something like to log
the exception.
【在 c*****t 的大作中提到】
: The problem is this, which happens quite often in library codes.
: Library A:
: try
: {
: foo (); // through injection, calls user function
: }
: catch (AException ex) // auto generated by IDE
: {
: printStackTrace ();
: }
|
|
|
s******n
发帖数: 876 | 21 devolpers will just declare "throws Exception" on all functions. ha!
【在 m******t 的大作中提到】
: It doesn't just remind the caller, it _forces_ the caller
: to deal with it when the caller may not want to or need to
: or be able to.
:
: Checked exception is a great way to remind the caller that, hey
: check the error before moving on. IllegalArgumentException just
: doesn't cut it since unless one is really looking for it, you
: won't know there is a problem until things break.
|
c*****t
发帖数: 1879 | 22 You misunderstood. foo () function part was all library code. Just
behind the scene that it calls user function.
In my experience, pretty much in all places where catch statement is
autogenerated, the code really means to catch all exceptions, including
runtime exceptions. However, throwing runtime exceptions would break
the code when actually it should not.
For example, one may check an string argument and throw an
IllegalArgumentException, then tries to use this string to open an file
(whic
【在 b******y 的大作中提到】
: the leak comes from this user function...
: why should the lib cover up for the user function?
: in reality case, if not showing odd exception to end user is a concern,
: you can add a catch (Exception ex) at the top level of presentation
: tier, and wrap it up there.
|
c*****t
发帖数: 1879 | 23 ... It is not about catched exception, it is about leaking exception.
RuntimeException can easily be leaked and break the existing code for
trivial matters.
【在 g*****g 的大作中提到】
: I wouldn't mind using RuntimeException as long as the caller
: cannot recover from it. Whenever I catch an exception, I would
: always call logger.error("...", e) or something like to log
: the exception.
|
w*****d
发帖数: 2415 | 24 An empty list is always better than null, always invoke the method and let
the object handle the behavior is always the correct way to do. You can
create a NullList class implementing List interface and assign several
default behaviors to it.
【在 b******y 的大作中提到】
: for functions like this:
: List search(...) {
: }
: When the search can't get anything, would you return null, or empty list?
|
