Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #30182 > unrolled thread

redesign exception

Back to article view | Back to comp.lang.java.programmer

Contents

  redesign exception boxzou@gmail.com - 2014-10-25 19:16 -0700
    Re: redesign exception Joerg Meier <joergmmeier@arcor.de> - 2014-10-26 08:09 +0100
      Re: redesign exception rossum <rossum48@coldmail.com> - 2014-10-26 09:15 +0000
        Re: redesign exception Joerg Meier <joergmmeier@arcor.de> - 2014-10-26 10:36 +0100
        Re: redesign exception Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-26 09:23 -0400
          Re: redesign exception boxzou@gmail.com - 2014-10-26 12:56 -0700
            Re: redesign exception Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-26 18:10 -0400
              Re: redesign exception boxzou@gmail.com - 2014-10-26 17:39 -0700
        Re: redesign exception boxzou@gmail.com - 2014-10-26 12:06 -0700
          Re: redesign exception Joerg Meier <joergmmeier@arcor.de> - 2014-10-26 20:41 +0100
      Re: redesign exception boxzou@gmail.com - 2014-10-26 12:46 -0700
        Re: redesign exception boxzou@gmail.com - 2014-10-26 13:12 -0700
        Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-26 16:50 -0500
          Re: redesign exception boxzou@gmail.com - 2014-10-26 17:21 -0700
        Re: redesign exception Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-27 01:05 +0000
          Re: redesign exception boxzou@gmail.com - 2014-10-26 19:38 -0700
            Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-27 00:13 -0500
              Re: redesign exception boxzou@gmail.com - 2014-10-27 04:59 -0700
              Re: redesign exception Marketa Jadalova <m-jadalova3@gmail.com> - 2014-10-27 16:55 +0000
                Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-27 12:46 -0500
                  Re: redesign exception boxzou@gmail.com - 2014-10-27 15:48 -0700
                    Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-27 22:16 -0500
                  Re: redesign exception Robert Klemme <shortcutter@googlemail.com> - 2014-10-27 23:54 +0100
                    Re: redesign exception boxzou@gmail.com - 2014-10-27 17:20 -0700
                    Re: redesign exception boxzou@gmail.com - 2014-10-28 07:12 -0700
                      Re: redesign exception Robert Klemme <shortcutter@googlemail.com> - 2014-10-29 08:34 +0100
                        Re: redesign exception Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-29 11:17 +0000
                          Re: redesign exception Silvio <silvio@internet.com> - 2014-10-29 15:33 +0100
                            Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-29 11:35 -0500
                              Re: redesign exception boxzou@gmail.com - 2014-10-29 17:51 -0700
                                Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-29 20:45 -0500
                                  Re: redesign exception boxzou@gmail.com - 2014-10-30 04:12 -0700
                                  Re: redesign exception Silvio <silvio@internet.com> - 2014-10-30 12:38 +0100
                                    Re: redesign exception boxzou@gmail.com - 2014-10-30 06:23 -0700
                            Re: redesign exception boxzou@gmail.com - 2014-10-29 17:01 -0700
                          Re: redesign exception Marketa Jadalova <m-jadalova3@gmail.com> - 2014-10-29 16:55 +0000
                            Re: redesign exception Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-29 17:29 +0000
                              Re: redesign exception Robert Klemme <shortcutter@googlemail.com> - 2014-10-29 18:59 +0100
                                Re: redesign exception Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-29 22:05 +0000
                              Re: redesign exception boxzou@gmail.com - 2014-10-29 18:04 -0700
                                Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-29 20:56 -0500
                                  Re: redesign exception boxzou@gmail.com - 2014-10-30 04:19 -0700
                                    Re: redesign exception boxzou@gmail.com - 2014-10-30 04:27 -0700
                                      Re: redesign exception boxzou@gmail.com - 2014-10-30 04:35 -0700
                            Re: redesign exception boxzou@gmail.com - 2014-10-29 18:01 -0700
                          Re: redesign exception boxzou@gmail.com - 2014-10-29 17:00 -0700
                        Re: redesign exception boxzou@gmail.com - 2014-10-29 16:56 -0700
      Re: redesign exception boxzou@gmail.com - 2014-10-26 12:52 -0700
    Re: redesign exception Silvio <silvio@internet.com> - 2014-10-27 09:03 +0100
      Re: redesign exception boxzou@gmail.com - 2014-10-27 05:06 -0700
        Re: redesign exception Silvio <silvio@internet.com> - 2014-10-27 13:32 +0100
          Re: redesign exception boxzou@gmail.com - 2014-10-27 07:01 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#30216

> Basically because the JDBC API is old and pretty badly done. The lack of
> good error mode descriptions at an appropriate level of abstraction is
> just _one_ of the many issues it has. It really is time we got new and 
> improved API for database connections.

Don't you think this time we should really define the exception codes instead of exceptions?

[toc] | [prev] | [next] | [standalone]

#30220

boxzou@gmail.com wrote:
>
> Don't you think this time we should really define the exception codes instead of exceptions?

No, I don't see that having any benefits over a properly designed exception 
hierarcy.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#30218

On 27.10.2014 18:46, Leif Roar Moldskred wrote:

> Basically because the JDBC API is old and pretty badly done. The lack of
> good error mode descriptions at an appropriate level of abstraction is
> just _one_ of the many issues it has. It really is time we got new and
> improved API for database connections.

I couldn't agree more!  I have long waited for sub classes of 
SQLException that at least distinguish basic error classes, e.g.
  - SQLConnectionException: network or other connectivity issues
  - SQLConstraintException: trying to insert a duplicate PK
  - SQLResourceException: server could not fulfill the query because of 
lacking tmp tablespace, memory or what
  - SQLSyntaxException: should be obvious

I think that would be enough to do a lot better error handling.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#30219

> I couldn't agree more!  I have long waited for sub classes of 
> SQLException that at least distinguish basic error classes, e.g.
>   - SQLConnectionException: network or other connectivity issues
>   - SQLConstraintException: trying to insert a duplicate PK
>   - SQLResourceException: server could not fulfill the query because of 
> lacking tmp tablespace, memory or what
>   - SQLSyntaxException: should be obvious
> 
> I think that would be enough to do a lot better error handling.

I agree this would be significantly better.

To remove the guess work handling exception, I think we need very specific codes.

For example, to handle primary key constraint violation, I caught SQLIntegrityConstraintViolationException because that's what was thrown when duplicate entry was inserted into a table.  But later I found out that SQLIntegrityConstraintViolationException is also thrown when non-null constraint is violated.  This kind of guess work can be eliminated when we have detailed codes.

[toc] | [prev] | [next] | [standalone]

#30224

>   - SQLConnectionException: network or other connectivity issues

SQLConnectionException would not be needed if we don't have checked exception and we don't catch the exceptions we can't handle.

[toc] | [prev] | [next] | [standalone]

#30230

On 28.10.2014 15:12, boxzou@gmail.com wrote:
>> - SQLConnectionException: network or other connectivity issues
>
> SQLConnectionException would not be needed if we don't have checked
> exception and we don't catch the exceptions we can't handle.

That does not make sens: one would still want to be able to catch this 
specific type of error.

Cheers

	robert

[toc] | [prev] | [next] | [standalone]

#30232

On Wed, 29 Oct 2014 08:34:41 +0100, Robert Klemme wrote:

> On 28.10.2014 15:12, boxzou@gmail.com wrote:
>>> - SQLConnectionException: network or other connectivity issues
>>
>> SQLConnectionException would not be needed if we don't have checked
>> exception and we don't catch the exceptions we can't handle.
> 
> That does not make sens: one would still want to be able to catch this
> specific type of error.
>
He also doesn't seem to realise that you can let all the checked 
Exceptions you don't want to handle individually percolate up to the 
outer layer of a program where a catch (Exception) can deal with them by 
walking with Exception chains and printing the messages they contain 
before terminating the program.

I tend to do that with all SQL related Exceptions that aren't directly 
related to the query, i.e. syntactic errors, miss-spelt column names etc 
- in short the type of error that isn't recoverable. This is easy to 
implement and can give good error diagnostics if carefully implemented.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#30233

On 29-10-14 12:17, Martin Gregorie wrote:
> On Wed, 29 Oct 2014 08:34:41 +0100, Robert Klemme wrote:
>
>> On 28.10.2014 15:12, boxzou@gmail.com wrote:
>>>> - SQLConnectionException: network or other connectivity issues
>>>
>>> SQLConnectionException would not be needed if we don't have checked
>>> exception and we don't catch the exceptions we can't handle.
>>
>> That does not make sens: one would still want to be able to catch this
>> specific type of error.
>>
> He also doesn't seem to realise that you can let all the checked
> Exceptions you don't want to handle individually percolate up to the
> outer layer of a program where a catch (Exception) can deal with them by
> walking with Exception chains and printing the messages they contain
> before terminating the program.
>
> I tend to do that with all SQL related Exceptions that aren't directly
> related to the query, i.e. syntactic errors, miss-spelt column names etc
> - in short the type of error that isn't recoverable. This is easy to
> implement and can give good error diagnostics if carefully implemented.
>
>

Nonetheless, if there is one thing I could change about exceptions than 
that would be ditching checked exceptions. Without a second thought.

[toc] | [prev] | [next] | [standalone]

#30235

Silvio <silvio@internet.com> wrote:
> 
> Nonetheless, if there is one thing I could change about exceptions than 
> that would be ditching checked exceptions. Without a second thought.
>

I'd like to keep the ability to force the caller to explicitly write
a handler for an exception, but I don't see any reason to tie that
into the type system. The /throws/ description in the method signature
should be enough to require an appropriate catch block (or matching 
/throws/ description in the calling method.)

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#30244

> 
> I'd like to keep the ability to force the caller to explicitly write
> a handler for an exception, but I don't see any reason to tie that
> into the type system. The /throws/ description in the method signature
> should be enough to require an appropriate catch block (or matching 
> /throws/ description in the calling method.)

I don't think so.  I think forcing the caller to handle the exception through checked exception is bad.

For example, you implemented a method getPropertiesFromFile(fileName), it calls the new FileInputStream(fileName) which throws FileNotFoundException, a checked exception.  Can you handle this exception in getPropertiesFromFile()?  If so, how?

Another scenario: one client calls your getPropertiesFromFile() to retrieve some properties that must be set, if the property file does not exist, this client simply prints the message and exists (this is exception handling, human is the handler).  Another client calls the same getPropertiesFromFile() to retrieve properties, but if the file does not exist (FileNotFoundException), this client just uses some default values (software handles the exception).  If getPropertiesFromFile() handles the exception, how can the client know that the file does not exist?

As we stare at stack trace, we will see method M1 calls M2, M2 calls M3, M4......., often many many methods, say the last one is M50.  An exception thrown at M50, M49 probably does not know how to process it because M50 was refactored out from M49, no matter what you do to force M49 to handle it, M49 still does not know how to handle it.

So Exception should bubble up, only the ones know how to handle it should catch it.  Others should leave it alone.

Because Exception is exceptional, handling it should be exceptional too.  Handling exceptional situation by always catching it is wrong.  Exception handling code should be rare.

Logging should be at the top level or at system boundary, like Web server, standalone default exception handler etc.

Note, it's hard to tell which error condition is bug, which condition is normal.  For example, in some programs, FileNot fFoundException indicate a bug because the file location was constructed wrong, while in other programs, it's operation error (ops forgot to put the file there).  In still others, it's perfectly OK to have this exception.  The ultimate caller (not immediate caller) should decide if it is a bug, error or normal.

[toc] | [prev] | [next] | [standalone]

#30247

boxzou@gmail.com wrote:
>> 
>> I'd like to keep the ability to force the caller to explicitly write
>> a handler for an exception, but I don't see any reason to tie that
>> into the type system. The /throws/ description in the method signature
>> should be enough to require an appropriate catch block (or matching 
>> /throws/ description in the calling method.)
> 

> I don't think so.  I think forcing the caller to handle the exception 
> through checked exception is bad.
> 
> For example, you implemented a method getPropertiesFromFile(fileName), it 
> calls the new FileInputStream(fileName) which throws FileNotFoundException, 
> a checked exception.  Can you handle this exception in getPropertiesFromFile()?  
> If so, how?

You're not forcing the caller to /resolve/ the exception, though -- he could
always just pass it upwards, either in a checked manner through a matching
/throws/ description of his own, or in an unchecked manner by 

The point of checked exceptions is to make sure the caller makes an explicit
_choice_ about handling an error mode in situ or passing the buck on further
up the chain and doesn't just overlook the possibility of that error entirely.

The problem with only using unchecked exceptions is that, even if all the APIs
are actually properly documented about which exceptions they can throw (which
they _never_ are), you quickly lose control after only a few levels of calls.

"FileNotFoundException? _Which_ file? The config file for Foo or the data file
for Bar?"

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#30250

> > I don't think so.  I think forcing the caller to handle the exception 
> > through checked exception is bad.
> > 
> > For example, you implemented a method getPropertiesFromFile(fileName), it 
> > calls the new FileInputStream(fileName) which throws FileNotFoundException, 
> > a checked exception.  Can you handle this exception in getPropertiesFromFile()?  
> > If so, how?
> 
> You're not forcing the caller to /resolve/ the exception, though -- he could
> always just pass it upwards, either in a checked manner through a matching
> /throws/ description of his own, or in an unchecked manner by 
> 
> The point of checked exceptions is to make sure the caller makes an explicit
> _choice_ about handling an error mode in situ or passing the buck on further
> up the chain and doesn't just overlook the possibility of that error entirely.

pass it on eventually ends up with so many exceptions on method throws part, once there are too many, it will be replaced with Exception which does not say anything.

for example, A calls B1, B2, B3, B4, B1 calls B1C1, B1C2, B1C3, B2 calls B2D1, B2D2, B2D3, suppose B1C1, B1C2, B1C3, B2D1, B2D2, B2D3 all throw distinct Exceptions like B1C1Ex, B2C2Ex ..., soon the method is full of exceptions in the throws part.  The call graph is only 2 level deep here.  Suppose it's 50 level deep, still want to list all the exceptions in throws?  This is exactly why framework like Spring, Hibernate, EclipseLink all chose unchecked exception.

> 
> The problem with only using unchecked exceptions is that, even if all the APIs
> are actually properly documented about which exceptions they can throw (which
> they _never_ are), you quickly lose control after only a few levels of calls.
> 

With checked exceptions, it is worse.  At best, a lot of methods signature will become "throws Exception", you don't have a clue about what exception is thrown any way.  What usually happens is exception will be caught and chained many times (in the stack trace, you'll see many Caused by).  And many times, the exception is simply swallowed or a message is printed and the stack trace is lost (stack trace is usually much valued than just message).

> "FileNotFoundException? _Which_ file? The config file for Foo or the data file
> for Bar?"
> 
Devil is in the details.  A few important and detailed information should be part of the exception:

1. code: for software to handle exception, FileNotFoundException is code here but in SQLException there are many different codes, the way to specify codes should be standardized in the language.  Right now it is up to each exception writer to design and implement.
2. message: for human to handle exception: e.g. "file {0} not found", "unique constraint {0} is violated" etc
3. parameters: to fill out the details, e.g. "/path/to/my.properties", "first_last_name_unique_constraint".  The way to specify parameters should also be standardized in the language.
4. stack trace: this is very important, some times more important than message.  do not swallow this information when handling exception.

[toc] | [prev] | [next] | [standalone]

#30254

You are probably aware that you mainly force callers to either:

- pass exceptions upwards by adding a throws clause (viral)
- absorb exceptions with a try-catch that at best prints stacktraces to 
stderr
- absorb exceptions by retrowing them wrapped in a different checked one 
(just because that was already "taken care off") or even worse, an 
unchecked one

which are all three an explicit way of implicitly saying they want an 
exception they do not care about or do not want to handle here out of 
their face.

This just adds to the volume of code bloat we usually call Java source 
code and probably makes the general exception handling in Java code less 
well-structured and thought through than in code written in languages 
with unchecked exceptions.

Apart from Java all subsequent JVM languages (as well as the non-JVM 
ones) have chosen to ignore the concept of checked exceptions. On the 
JVM it is just a façade put up by the compiler since the JVM could not 
care less.

It was a bad idea at the time and in retrospect it is probably one that 
the original inventors regret. But as with many things with Java it is 
far too late to do anything about it, even if in this case it would be 
technically easy to just remove the check from the compiler. The 
disruption to Java programmers who have been fed the idea would be 
considered too great for this to ever happen.


On 30-10-14 02:45, Leif Roar Moldskred wrote:
> boxzou@gmail.com wrote:
>>>
>>> I'd like to keep the ability to force the caller to explicitly write
>>> a handler for an exception, but I don't see any reason to tie that
>>> into the type system. The /throws/ description in the method signature
>>> should be enough to require an appropriate catch block (or matching
>>> /throws/ description in the calling method.)
>>
>
>> I don't think so.  I think forcing the caller to handle the exception
>> through checked exception is bad.
>>
>> For example, you implemented a method getPropertiesFromFile(fileName), it
>> calls the new FileInputStream(fileName) which throws FileNotFoundException,
>> a checked exception.  Can you handle this exception in getPropertiesFromFile()?
>> If so, how?
>
> You're not forcing the caller to /resolve/ the exception, though -- he could
> always just pass it upwards, either in a checked manner through a matching
> /throws/ description of his own, or in an unchecked manner by
>
> The point of checked exceptions is to make sure the caller makes an explicit
> _choice_ about handling an error mode in situ or passing the buck on further
> up the chain and doesn't just overlook the possibility of that error entirely.
>
> The problem with only using unchecked exceptions is that, even if all the APIs
> are actually properly documented about which exceptions they can throw (which
> they _never_ are), you quickly lose control after only a few levels of calls.
>
> "FileNotFoundException? _Which_ file? The config file for Foo or the data file
> for Bar?"
>

[toc] | [prev] | [next] | [standalone]

#30255

Exactly!  I totally agree with what you said here.

Through Java's experimentation, we are now clear checked exception is BAD!  Unfortunately a lot of developers were taught that checked exception is good and they still think that way and tenaciously hold onto that idea.  This education has to be undone.

One of the way to undo the teaching is to use the mechanism I proposed in the original post.  Because there is only one exception type (Fault), it does not make sense to make it checked.  So we can do away with checked exception in a backward compatible manner.

On Thursday, 30 October 2014 07:39:04 UTC-4, Silvio  wrote:
> You are probably aware that you mainly force callers to either:
> 
> - pass exceptions upwards by adding a throws clause (viral)
> - absorb exceptions with a try-catch that at best prints stacktraces to 
> stderr
> - absorb exceptions by retrowing them wrapped in a different checked one 
> (just because that was already "taken care off") or even worse, an 
> unchecked one
> 
> which are all three an explicit way of implicitly saying they want an 
> exception they do not care about or do not want to handle here out of 
> their face.
> 
> This just adds to the volume of code bloat we usually call Java source 
> code and probably makes the general exception handling in Java code less 
> well-structured and thought through than in code written in languages 
> with unchecked exceptions.
> 
> Apart from Java all subsequent JVM languages (as well as the non-JVM 
> ones) have chosen to ignore the concept of checked exceptions. On the 
> JVM it is just a façade put up by the compiler since the JVM could not 
> care less.
> 
> It was a bad idea at the time and in retrospect it is probably one that 
> the original inventors regret. But as with many things with Java it is 
> far too late to do anything about it, even if in this case it would be 
> technically easy to just remove the check from the compiler. The 
> disruption to Java programmers who have been fed the idea would be 
> considered too great for this to ever happen.
> 
> 
> On 30-10-14 02:45, Leif Roar Moldskred wrote:
> > bo...@gmail.com wrote:
> >>>
> >>> I'd like to keep the ability to force the caller to explicitly write
> >>> a handler for an exception, but I don't see any reason to tie that
> >>> into the type system. The /throws/ description in the method signature
> >>> should be enough to require an appropriate catch block (or matching
> >>> /throws/ description in the calling method.)
> >>
> >
> >> I don't think so.  I think forcing the caller to handle the exception
> >> through checked exception is bad.
> >>
> >> For example, you implemented a method getPropertiesFromFile(fileName), it
> >> calls the new FileInputStream(fileName) which throws FileNotFoundException,
> >> a checked exception.  Can you handle this exception in getPropertiesFromFile()?
> >> If so, how?
> >
> > You're not forcing the caller to /resolve/ the exception, though -- he could
> > always just pass it upwards, either in a checked manner through a matching
> > /throws/ description of his own, or in an unchecked manner by
> >
> > The point of checked exceptions is to make sure the caller makes an explicit
> > _choice_ about handling an error mode in situ or passing the buck on further
> > up the chain and doesn't just overlook the possibility of that error entirely.
> >
> > The problem with only using unchecked exceptions is that, even if all the APIs
> > are actually properly documented about which exceptions they can throw (which
> > they _never_ are), you quickly lose control after only a few levels of calls.
> >
> > "FileNotFoundException? _Which_ file? The config file for Foo or the data file
> > for Bar?"
> >

[toc] | [prev] | [next] | [standalone]

#30242

> 
> Nonetheless, if there is one thing I could change about exceptions than 
> that would be ditching checked exceptions. Without a second thought.

Totally agree!  Most unnecessary try/catch were caused by checked exception.

[toc] | [prev] | [next] | [standalone]

#30236

In article m2qics$d01$1@dont-email.me, Martin Gregorie
<martin@address-in-sig.invalid> wrote:

> I tend to do that with all SQL related Exceptions that aren't directly
> related to the query, i.e. syntactic errors, miss-spelt column names etc
> - in short the type of error that isn't recoverable. This is easy to
> implement and can give good error diagnostics if carefully implemented.

It strikes me as odd that they didn't create an SQLRuntimeException class 
(derived from RuntimeException) for the SQL errors that likely represent 
bugs in your code (syntactically malformed queries, column doesn't exist, 
etc.) and reserve the (checked) SQLException hierarchy for ones that can 
arise even if there is no bug in the application (or mismatch of some 
sort between the application and the database), such as I/O errors and 
constraint violations.

That's the usual pattern elsewhere in Javaland, after all: 
RuntimeException (and Error) for cases that need the application code 
changing to fix, and (checked) Exception for cases that can arise without 
broken application code, but as errors that are (or, at least, often are) 
something else's fault (user error, network, or whatever).

Funnily enough, almost all of the exceptions I see in actual practice 
that are not programmer errors are IOExceptions or, at least, are I/O 
exceptions. :) User misspells filename to open: IOException. Network 
resource (or network itself) goes down: IOException. I'm wondering 
actually how often it even makes sense for a checked exception not to be 
considered, at least conceptually, to be an I/O exception.

[toc] | [prev] | [next] | [standalone]

#30237

On Wed, 29 Oct 2014 16:55:01 +0000, Marketa Jadalova wrote:

> It strikes me as odd that they didn't create an SQLRuntimeException
> class (derived from RuntimeException) for the SQL errors that likely
> represent bugs in your code (syntactically malformed queries, column
> doesn't exist,
> etc.) and reserve the (checked) SQLException hierarchy for ones that can
> arise even if there is no bug in the application (or mismatch of some
> sort between the application and the database), such as I/O errors and
> constraint violations.
> 
> That's the usual pattern elsewhere in Javaland, after all:
> RuntimeException (and Error) for cases that need the application code
> changing to fix, and (checked) Exception for cases that can arise
> without broken application code, but as errors that are (or, at least,
> often are)
> something else's fault (user error, network, or whatever).
>
Yes, that split into major Exception classes would be useful and would, 
have been trivially easy to do by subclassing SQLRuntimeException and 
SQLException. It would have been easy enough to generate the right 
Exception within the JDBC driver too; the underlying SQL error codes are 
given a structured set of values by every RDBMS I've used.
   
> Funnily enough, almost all of the exceptions I see in actual practice
> that are not programmer errors are IOExceptions or, at least, are I/O
> exceptions. :) User misspells filename to open: IOException. Network
> resource (or network itself) goes down: IOException. I'm wondering
> actually how often it even makes sense for a checked exception not to be
> considered, at least conceptually, to be an I/O exception.
>
This is probably due to code designed to not throw Exceptions just 
because input date is invalid. 

I believe a good case can be made that invalid data isn't really an 
Exception because having both good and bad data input is part of normal 
processing and therefore something like a boolean VALID/INVALID return 
from the checking method is alll that's needed. Throwing exceptions 
should be reserved for processing errors, e.g. a public holiday check on 
an in-range future date discovering that the valid public holiday list 
doesn't cover all permitted future dates, or finding that the input 
represents a security violation serious enough to require attention from 
somebody other than the user who input it.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#30238

On 29.10.2014 18:29, Martin Gregorie wrote:

> I believe a good case can be made that invalid data isn't really an
> Exception because having both good and bad data input is part of normal
> processing and therefore something like a boolean VALID/INVALID return
> from the checking method is alll that's needed. Throwing exceptions
> should be reserved for processing errors, e.g. a public holiday check on
> an in-range future date discovering that the valid public holiday list
> doesn't cover all permitted future dates, or finding that the input
> represents a security violation serious enough to require attention from
> somebody other than the user who input it.

We could discuss quite a bit about this...  If the interfacing code does 
not ensure valid input is passed on than it is totally appropriate for 
lower layers of code to flag this as a processing error (usually via a 
RuntimeException like InvalidArgumentException or NPE).  A checking 
method with a boolean (or more sophisticated) return value can only ever 
be a useful helper but the code receiving data still needs to throw if 
the contract is violated.  There is really no other way.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#30239

On Wed, 29 Oct 2014 18:59:47 +0100, Robert Klemme wrote:

> On 29.10.2014 18:29, Martin Gregorie wrote:
> 
>> I believe a good case can be made that invalid data isn't really an
>> Exception because having both good and bad data input is part of normal
>> processing and therefore something like a boolean VALID/INVALID return
>> from the checking method is alll that's needed. Throwing exceptions
>> should be reserved for processing errors, e.g. a public holiday check
>> on an in-range future date discovering that the valid public holiday
>> list doesn't cover all permitted future dates, or finding that the
>> input represents a security violation serious enough to require
>> attention from somebody other than the user who input it.
> 
> We could discuss quite a bit about this...  If the interfacing code does
> not ensure valid input is passed on than it is totally appropriate for
> lower layers of code to flag this as a processing error (usually via a
> RuntimeException like InvalidArgumentException or NPE).  A checking
> method with a boolean (or more sophisticated) return value can only ever
> be a useful helper but the code receiving data still needs to throw if
> the contract is violated.  There is really no other way.
>
Sure. I was only talking about parts of a program where invalid data 
should be expected as a normal part of the data stream, for instance 
around input validation methods that sit behind an input screen, which 
are going to recycle bad input by telling the user what's wrong with his 
input and inviting corrected data to be supplied. You do the same with 
incoming mail. An invalid recipient address isn't really exceptional: you 
get them all the time and spit them back whence they came with a 5xx SMTP 
error, meanwhile passing clean input on to the archiving and delivery 
systems.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#30246

Why generate the exceptions from error codes?  Just because Java's catch only catch Exception type. What if java's catch is extended to catch code?  This is exactly what I am posting about.

Error codes is the way to go.

> > It strikes me as odd that they didn't create an SQLRuntimeException
> > class (derived from RuntimeException) for the SQL errors that likely
> > represent bugs in your code (syntactically malformed queries, column
> > doesn't exist,
> > etc.) and reserve the (checked) SQLException hierarchy for ones that can
> > arise even if there is no bug in the application (or mismatch of some
> > sort between the application and the database), such as I/O errors and
> > constraint violations.
> > 
> > That's the usual pattern elsewhere in Javaland, after all:
> > RuntimeException (and Error) for cases that need the application code
> > changing to fix, and (checked) Exception for cases that can arise
> > without broken application code, but as errors that are (or, at least,
> > often are)
> > something else's fault (user error, network, or whatever).
> >
> Yes, that split into major Exception classes would be useful and would, 
> have been trivially easy to do by subclassing SQLRuntimeException and 
> SQLException. It would have been easy enough to generate the right 
> Exception within the JDBC driver too; the underlying SQL error codes are 
> given a structured set of values by every RDBMS I've used.
>    
> > Funnily enough, almost all of the exceptions I see in actual practice
> > that are not programmer errors are IOExceptions or, at least, are I/O
> > exceptions. :) User misspells filename to open: IOException. Network
> > resource (or network itself) goes down: IOException. I'm wondering
> > actually how often it even makes sense for a checked exception not to be
> > considered, at least conceptually, to be an I/O exception.
> >
> This is probably due to code designed to not throw Exceptions just 
> because input date is invalid. 
> 
> I believe a good case can be made that invalid data isn't really an 
> Exception because having both good and bad data input is part of normal 
> processing and therefore something like a boolean VALID/INVALID return 
> from the checking method is alll that's needed. Throwing exceptions 
> should be reserved for processing errors, e.g. a public holiday check on 
> an in-range future date discovering that the valid public holiday list 
> doesn't cover all permitted future dates, or finding that the input 
> represents a security violation serious enough to require attention from 
> somebody other than the user who input it.
> 
> 
> -- 
> martin@   | Martin Gregorie
> gregorie. | Essex, UK
> org       |

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web