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 3 of 3 — ← Prev page 1 2 [3]

#30248

boxzou@gmail.com wrote:
> 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.

Knock yourself out:

public class ErrorCode implements RuntimeException {
  private final int code;
  private final String description;

  public ErrorCode( int code ) { ... }
  public ErrorCode( int code, String description ) { ... }
  public ErrorCode( int code, Throwable t ) { ... }
  public ErrorCode( int code, String description, Throwable T ) { ... }

  public int getCode() { ... }
  public String getDescription() { ... }
}


try {
  doStuff();
} catch( ErrorCode error ) {
  switch( error.getCode() ) {
   ...
  }
}


-- 
Leif Roar Moldskred

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

#30251

> > Error codes is the way to go.
> 
> Knock yourself out:
I don't know what it means cause I am not a native English speaker :)

I want to add a new way of catch exception in the java language:
    catch (Fault fault, someExceptionCodes)
someExceptionCodes will be varargs.

so no "switch( error.getCode() )" is required.

I actually imitated the syntax with lambda in java 8.  Here is the blog and  code:

http://tri-katch.blogspot.ca
The github project is: https://github.com/pahakia/lib.
Java 8 example: https://github.com/pahakia/lambda.
https://github.com/pahakia/lambda/tree/master/fault-test/src/test/java/pahakia/fault/lambda.

taken from the blog:
Java 8:
        int num = tri(() -> {
            str.length();
            return Integer.valueOf(str);
        }).katch(JreFaultCodes.NumberFormatException_java_lang, ex -> {
            System.out.println("processing NumberFormatException: " + ex);
            return 400;
        }).katch(JreFaultCodes.NullPointerException_java_lang, ex -> {
            System.out.println("processing NullPointException: " + ex);
            return 500;
        }).finale(() -> {
            System.out.println("hello");
        });

The syntax is a little clumsy here because I am using lambda to simulate a language change.

> 
> public class ErrorCode implements RuntimeException {
>   private final int code;
>   private final String description;
> 
>   public ErrorCode( int code ) { ... }
>   public ErrorCode( int code, String description ) { ... }
>   public ErrorCode( int code, Throwable t ) { ... }
>   public ErrorCode( int code, String description, Throwable T ) { ... }
> 
>   public int getCode() { ... }
>   public String getDescription() { ... }
> }
> 
> 
> try {
>   doStuff();
> } catch( ErrorCode error ) {
>   switch( error.getCode() ) {
>    ...
>   }
> }
> 
> 
> -- 
> Leif Roar Moldskred

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

#30252

If the new catch syntax is added, the equivalent code would be:

        try {
            str.length();
            return Integer.valueOf(str);
        } catch(Fault ex, JreFaultCodes.NumberFormatException_java_lang) {
            System.out.println("processing NumberFormatException: " + ex);
        } catch(Fault ex, JreFaultCodes.NullPointerException_java_lang) {
            System.out.println("processing NullPointException: " + ex);
        } finally {
            System.out.println("hello");
        };

Fault ex is no longer used as a condition, the code like JreFaultCodes.NumberFormatException_java_lang is.

> Java 8:
>         int num = tri(() -> {
>             str.length();
>             return Integer.valueOf(str);
>         }).katch(JreFaultCodes.NumberFormatException_java_lang, ex -> {
>             System.out.println("processing NumberFormatException: " + ex);
>             return 400;
>         }).katch(JreFaultCodes.NullPointerException_java_lang, ex -> {
>             System.out.println("processing NullPointException: " + ex);
>             return 500;
>         }).finale(() -> {
>             System.out.println("hello");
>         });
> 
> The syntax is a little clumsy here because I am using lambda to simulate a language change.
> 
> > 
> > public class ErrorCode implements RuntimeException {
> >   private final int code;
> >   private final String description;
> > 
> >   public ErrorCode( int code ) { ... }
> >   public ErrorCode( int code, String description ) { ... }
> >   public ErrorCode( int code, Throwable t ) { ... }
> >   public ErrorCode( int code, String description, Throwable T ) { ... }
> > 
> >   public int getCode() { ... }
> >   public String getDescription() { ... }
> > }
> > 
> > 
> > try {
> >   doStuff();
> > } catch( ErrorCode error ) {
> >   switch( error.getCode() ) {
> >    ...
> >   }
> > }
> > 
> > 
> > -- 
> > Leif Roar Moldskred

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

#30253

The two catches can be merged into 1:

        try { 
            str.length(); 
            return Integer.valueOf(str); 
        } catch(Fault ex, NumberFormatException_java_lang, NullPointerException_java_lang) { 
            System.out.println("processing " + ex.getCode() + ": " + ex); 
        } finally { 
            System.out.println("hello"); 
        }; 

> If the new catch syntax is added, the equivalent code would be:
> 
>         try {
>             str.length();
>             return Integer.valueOf(str);
>         } catch(Fault ex, JreFaultCodes.NumberFormatException_java_lang) {
>             System.out.println("processing NumberFormatException: " + ex);
>         } catch(Fault ex, JreFaultCodes.NullPointerException_java_lang) {
>             System.out.println("processing NullPointException: " + ex);
>         } finally {
>             System.out.println("hello");
>         };
> 
> Fault ex is no longer used as a condition, the code like JreFaultCodes.NumberFormatException_java_lang is.
> 

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

#30245

> 
> > 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.

Logically group exceptions is OK.  But make exception checked is bad.

There are many exceptions other than I/O exceptions, user input definitely can cause all kinds of errors.  Race conditions can create weird error conditions, etc.  We often see I/O exceptions because it crosses system boundaries and access points can't be limited or enforced.

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

#30241

On Wednesday, 29 October 2014 07:18:09 UTC-4, Martin Gregorie  wrote:
> On Wed, 29 Oct 2014 08:34:41 +0100, Robert Klemme wrote:
> 
> > On 28.10.2014 15:12, box...@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.
> 
I don't quite follow you here.  If it's checked exception, you either have to declares throws, or catch it.  How do you percolate up?  wrap it in an unchecked exception like RuntimeException?

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

#30240

On Wednesday, 29 October 2014 03:34:56 UTC-4, Robert Klemme  wrote:
> On 28.10.2014 15:12, box...@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.
> 
You can still catch those errors.  The exceptions are unchecked exceptions and if no one catches them before your code, of course you can still catch them.

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

#30190

The scalability problems lies in that each public class must be in its own file.  So I can list 850 codes in one class file (bit too long, I agree, it should have been broken down into a few files).  But 850 files is much more time consuming to write.  And we don't need to do so.

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

#30200

Simply switch to Scala's exception syntax and most of your problem goes 
away:

try
{
    // something dangerous
}
catch
{
    case x : java.sql.SQLException if x.getErrorCode() == 14 => // SQL 14
    case x : Exception => println(x.getMessage)
}

Scala extends its pattern matching syntax to handle exceptions. If you 
define your user exceptions as case classes (special type of class that 
automagically has extended support for pattern matching) you can not 
only catch cases based on class and an if-clause but specify any pattern 
that Scala pattern matching supports.

This not only allows more fine-grained handling but also enables you to 
extract exception fields/details while matching. Too much to summarize 
here, I suggest you look into Scala pattern matching.

Oh, and in Scala you can put as many classes in a source as you want. 
That might be a nice change to Java as well...

Then again, as a variation on a common saying: if it's too much broken 
don't fix it...

On 10/26/2014 03:16 AM, boxzou@gmail.com wrote:
> I think Java exception need an overhaul.  Here is why:
>
> 1. exception handling need very specific information (like primary key constraint violation).  For human, a detailed message is required, for software a code is required.
>
> 2. this code information currently is implemented partly as exception type.  But that is not enough, so some projects augment it with code like in SQLException (e.g. https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_(ELUG)).
>
> 3. As there are so many exception codes (refer to the EclipseLink above), they can't be implemented using exception types in a scalable manner.  And they don't need to.  Essentially we are treating Exception types (conceptually some strings too) as codes.  So let's go back to just exception codes (strings).
>
> 4. If necessary, we can organize code into hierarchy: e.g. ReflectiveOperationException.NoSuchMethodFoundException.  So you can either catch the more specific code NoSuchMethodFoundException or a broader code ReflectiveOperationException.  This simulates catching super class exception.
>
> 5. With codes, it's much easier to define: for example, JreFaultCodes (https://github.com/pahakia/lib/blob/master/fault/src/main/java/pahakia/fault/JreFaultCodes.java) lists all about 850 Exceptions/Errors in JRE.
>
> 6. So I propose only one exception type: Fault.  And one exception code type: FaultCode.
>
> 6. The new catch syntax would be: catch(someExceptionCode, Fault fault).
>
> For more details, please read my blog: http://tri-katch.blogspot.ca
>

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

#30202

What I'd really like to achieve is to be able to say:

case x : java.sql.SQLException.14 

Language does not matter.  The problem I posted about is across all OO languages.

Other points:
1. standardize the details as parameters
2. documentation and I18N support through messageTemplate.

The new exception handling mechanism can be added in a backward compatible manner so nothing would be broken.

The current way one public class per  Java file has its advantage:  so easy to search for a class.

On Monday, 27 October 2014 04:03:43 UTC-4, Silvio  wrote:
> Simply switch to Scala's exception syntax and most of your problem goes 
> away:
> 
> try
> {
>     // something dangerous
> }
> catch
> {
>     case x : java.sql.SQLException if x.getErrorCode() == 14 => // SQL 14
>     case x : Exception => println(x.getMessage)
> }
> 
> Scala extends its pattern matching syntax to handle exceptions. If you 
> define your user exceptions as case classes (special type of class that 
> automagically has extended support for pattern matching) you can not 
> only catch cases based on class and an if-clause but specify any pattern 
> that Scala pattern matching supports.
> 
> This not only allows more fine-grained handling but also enables you to 
> extract exception fields/details while matching. Too much to summarize 
> here, I suggest you look into Scala pattern matching.
> 
> Oh, and in Scala you can put as many classes in a source as you want. 
> That might be a nice change to Java as well...
> 
> Then again, as a variation on a common saying: if it's too much broken 
> don't fix it...
> 

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

#30203

Were SQLException a Scala case class or would someone add an extractor 
after the fact (which you can easily do yourself without breaking 
anything) that would become:

case SQLException(14) => println("SQL error 14")
case SQLException(15) => println("SQL error 15")
case SQLException(x) => println("SQL errror " + x)

where the latter would match any SQL exception extracting the number into x.

This is all about language, nothing else. Standardization on exception 
will not happen simply because there is no fixed format to catch all 
imaginable types of exceptions in. Exceptions in general can not be 
brought down to 1, 2 or any n fixed fields or values.

A language like Scala however, allows you to write such extractors for 
any given set of exception types that are relevant to your code.

A language designed for extensibility allows you to define this without 
having to change the language itself. Among others Scala is such a 
language, Java is not. Pattern matching is just an example but there is 
plenty more.


On 10/27/2014 01:06 PM, boxzou@gmail.com wrote:
> What I'd really like to achieve is to be able to say:
>
> case x : java.sql.SQLException.14
>
> Language does not matter.  The problem I posted about is across all OO languages.
>
> Other points:
> 1. standardize the details as parameters
> 2. documentation and I18N support through messageTemplate.
>
> The new exception handling mechanism can be added in a backward compatible manner so nothing would be broken.
>
> The current way one public class per  Java file has its advantage:  so easy to search for a class.
>
> On Monday, 27 October 2014 04:03:43 UTC-4, Silvio  wrote:
>> Simply switch to Scala's exception syntax and most of your problem goes
>> away:
>>
>> try
>> {
>>      // something dangerous
>> }
>> catch
>> {
>>      case x : java.sql.SQLException if x.getErrorCode() == 14 => // SQL 14
>>      case x : Exception => println(x.getMessage)
>> }
>>
>> Scala extends its pattern matching syntax to handle exceptions. If you
>> define your user exceptions as case classes (special type of class that
>> automagically has extended support for pattern matching) you can not
>> only catch cases based on class and an if-clause but specify any pattern
>> that Scala pattern matching supports.
>>
>> This not only allows more fine-grained handling but also enables you to
>> extract exception fields/details while matching. Too much to summarize
>> here, I suggest you look into Scala pattern matching.
>>
>> Oh, and in Scala you can put as many classes in a source as you want.
>> That might be a nice change to Java as well...
>>
>> Then again, as a variation on a common saying: if it's too much broken
>> don't fix it...
>>

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

#30205

> case SQLException(14) => println("SQL error 14")
This is very close to what I want.  It would be better if we don't have to write any extractor at all.

Fault(FaultCode code, String...args): args is varargs, the length is validated against numArgs in FaultCode.
FaultCode(String code, int numArgs, String messageTemplate).

Scala is a very interesting language.  Competition drives innovation.

Thanks.

On Monday, 27 October 2014 08:32:32 UTC-4, Silvio  wrote:
> Were SQLException a Scala case class or would someone add an extractor 
> after the fact (which you can easily do yourself without breaking 
> anything) that would become:
> 
> case SQLException(14) => println("SQL error 14")
> case SQLException(15) => println("SQL error 15")
> case SQLException(x) => println("SQL errror " + x)
> 
> where the latter would match any SQL exception extracting the number into x.
> 
> This is all about language, nothing else. Standardization on exception 
> will not happen simply because there is no fixed format to catch all 
> imaginable types of exceptions in. Exceptions in general can not be 
> brought down to 1, 2 or any n fixed fields or values.
> 
> A language like Scala however, allows you to write such extractors for 
> any given set of exception types that are relevant to your code.
> 
> A language designed for extensibility allows you to define this without 
> having to change the language itself. Among others Scala is such a 
> language, Java is not. Pattern matching is just an example but there is 
> plenty more.
> 
> 
> On 10/27/2014 01:06 PM, box...@gmail.com wrote:
> > What I'd really like to achieve is to be able to say:
> >
> > case x : java.sql.SQLException.14
> >
> > Language does not matter.  The problem I posted about is across all OO languages.
> >
> > Other points:
> > 1. standardize the details as parameters
> > 2. documentation and I18N support through messageTemplate.
> >
> > The new exception handling mechanism can be added in a backward compatible manner so nothing would be broken.
> >
> > The current way one public class per  Java file has its advantage:  so easy to search for a class.
> >
> > On Monday, 27 October 2014 04:03:43 UTC-4, Silvio  wrote:
> >> Simply switch to Scala's exception syntax and most of your problem goes
> >> away:
> >>
> >> try
> >> {
> >>      // something dangerous
> >> }
> >> catch
> >> {
> >>      case x : java.sql.SQLException if x.getErrorCode() == 14 => // SQL 14
> >>      case x : Exception => println(x.getMessage)
> >> }
> >>
> >> Scala extends its pattern matching syntax to handle exceptions. If you
> >> define your user exceptions as case classes (special type of class that
> >> automagically has extended support for pattern matching) you can not
> >> only catch cases based on class and an if-clause but specify any pattern
> >> that Scala pattern matching supports.
> >>
> >> This not only allows more fine-grained handling but also enables you to
> >> extract exception fields/details while matching. Too much to summarize
> >> here, I suggest you look into Scala pattern matching.
> >>
> >> Oh, and in Scala you can put as many classes in a source as you want.
> >> That might be a nice change to Java as well...
> >>
> >> Then again, as a variation on a common saying: if it's too much broken
> >> don't fix it...
> >>

[toc] | [prev] | [standalone]

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

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

csiph-web