Jump to page: 1 25  
Page
Thread overview
Exception programming difficult
Aug 12, 2012
Marco Leise
Possible "throws" syntax
Aug 12, 2012
Marco Leise
Aug 15, 2012
Dmitry Olshansky
Aug 17, 2012
Marco Leise
Aug 17, 2012
Dmitry Olshansky
Aug 17, 2012
Marco Leise
Aug 17, 2012
Dmitry Olshansky
Aug 19, 2012
foobar
Aug 19, 2012
Dmitry Olshansky
Aug 12, 2012
Jonathan M Davis
Aug 12, 2012
Timon Gehr
Aug 12, 2012
Walter Bright
Aug 12, 2012
Jonathan M Davis
Aug 15, 2012
SomeDude
Aug 12, 2012
Marco Leise
Aug 12, 2012
Paulo Pinto
Aug 12, 2012
bearophile
Aug 12, 2012
Paulo Pinto
Aug 13, 2012
Marco Leise
Aug 12, 2012
Walter Bright
Aug 15, 2012
SomeDude
Aug 12, 2012
Adam D. Ruppe
Aug 12, 2012
simendsjo
Aug 12, 2012
Jonathan M Davis
Aug 13, 2012
Regan Heath
Aug 13, 2012
Jacob Carlborg
Aug 13, 2012
Nathan M. Swan
Aug 13, 2012
Marco Leise
Aug 13, 2012
Marco Leise
Aug 13, 2012
Marco Leise
Aug 13, 2012
Nathan M. Swan
Aug 13, 2012
Marco Leise
Aug 15, 2012
SomeDude
Aug 16, 2012
Kagamin
Aug 18, 2012
SomeDude
Aug 17, 2012
Marco Leise
Aug 13, 2012
Dmitry Olshansky
Aug 13, 2012
Timon Gehr
Aug 13, 2012
Dmitry Olshansky
Aug 13, 2012
Timon Gehr
Aug 13, 2012
Marco Leise
Aug 14, 2012
Mehrdad
Aug 14, 2012
Mehrdad
Aug 15, 2012
Mehrdad
Aug 15, 2012
Paulo Pinto
Aug 17, 2012
Marco Leise
Aug 16, 2012
Manipulator
Aug 17, 2012
Marco Leise
August 12, 2012
I just got a bit frustrated and wanted to say that I like working with Exceptions in Java a lot more. That has to do first but not foremost with the declaration:

---Java->>

class MyException extends Exception {
  public MyException(String msg) {
    super(msg);
  }
  public MyException(String msg, Throwable next) {
    super(msg, next)
  }
}

<<-Java---
---D->>

class MyException : Exception {
  this(string msg, string file = __FILE__, size_t line = __LINE__, Throwable next = null) {
    super(msg, file, line, next);
  }
  this(string msg, Throwable next, string file = __FILE__, size_t line = __LINE__) {
    super(msg, file, line, next);
  }
}

<<-D---

The other think that I'd really like to see is an actual declaration for the user of a function to see what exceptions can be thrown - also inferred and checked by the compiler. In Java you cannot compile a function that throws some (checked) exception and doesn't declare that like this:

---Java->>

void foo() throws MyException {
  throw new MyException("test");
}

<<-Java---

This way you, as the author, are always aware of which Exceptions you handle inside the function and which may escape. This escalates to callers of the function as well, so that in the end the public API has an exact list of possibly thrown exceptions that the user must handle.
I have around a dozen different exceptions in a hierarchy and a few nested function calls. It's a maintenance horror to keep the DDoc up to date about thrown Exceptions. It also doesn't check the spelling or offers a link to the Exceptions.

---D->>

/**
 * Receives a response from the server.
 *
 * Some explanation of what
 * the function does in detail.
 *
 * Params:
 *    response = receives the whole response
 * Throws:
 *    UnexpectedResponseException if the server sent us garbage
 *
 *    UnauthenticatedException we need retry after we have logged in
 *
 *    SecurityException we have to switch to a secure connection for this
 *
 *    DisconnectException the connection was unexpectedly terminated
 * Returns: the associated response code
 */

<<-D---

I know that the Java way isn't perfect, because some lazy people write dummy exception handlers to silence the errors, but its a worse solution to _not_ notify the user of a function, that it potentially throws exceptions, I think. So I wish D was explicit about thrown Exceptions.

-- 
Marco

August 12, 2012
Am Sun, 12 Aug 2012 05:02:25 +0200
schrieb Marco Leise <Marco.Leise@gmx.de>:

> ---D->>
> 
> /**
>  * Receives a response from the server.
>  *
>  * Some explanation of what
>  * the function does in detail.
>  *
>  * Params:
>  *    response = receives the whole response
>  * Throws:
>  *    UnexpectedResponseException if the server sent us garbage
>  *
>  *    UnauthenticatedException we need retry after we have logged in
>  *
>  *    SecurityException we have to switch to a secure connection for this
>  *
>  *    DisconnectException the connection was unexpectedly terminated
>  * Returns: the associated response code
>  */
> int foo(out string response)
> {...}
> 
> <<-D---

could become:

---D->>

/**
 * Receives a response from the server.
 *
 * Some explanation of what
 * the function does in detail.
 *
 * Params:
 *    response = receives the whole response
 * Returns: the associated response code
 */
int foo(out string response) throws
    UnexpectedResponseException, /// if the server sent us garbage
    UnauthenticatedException, /// we need retry after we have logged in
    SecurityException, /// we have to switch to a secure connection for this
    DisconnectException /// the connection was unexpectedly terminated
{...}

<<-D--

So there would be no net change in typing required if that is a concern. Callers of the function could inherit from this documentation as well for their "throws" section, so you only have to rewrite the documetation if the reason for the exception needs to be formulated differently or multiple called functions throw the same exception.

-- 
Marco

August 12, 2012
On Sunday, August 12, 2012 05:02:25 Marco Leise wrote:
> I know that the Java way isn't perfect, because some lazy people write dummy exception handlers to silence the errors, but its a worse solution to _not_ notify the user of a function, that it potentially throws exceptions, I think. So I wish D was explicit about thrown Exceptions.

It's becoming more universally accepted that while checked exceptions seem like a great idea up front, they're ultimately a bad idea:

http://www.artima.com/intv/handcuffs.html

D has nothrow, which statically verifies that _no_ exceptions are thrown, but that's as close as it's going to get to having checked exceptions.

- Jonathan M Davis
August 12, 2012
On 08/12/2012 05:02 AM, Marco Leise wrote:
> I just got a bit frustrated and wanted to say that I like working with Exceptions in Java a lot more. That has to do first but not foremost with the declaration:
>
> ---Java->>
>
> class MyException extends Exception {
>    public MyException(String msg) {
>      super(msg);
>    }
>    public MyException(String msg, Throwable next) {
>      super(msg, next)
>    }
> }
>
> <<-Java---
> ---D->>
>
> class MyException : Exception {
>    this(string msg, string file = __FILE__, size_t line = __LINE__, Throwable next = null) {
>      super(msg, file, line, next);
>    }
>    this(string msg, Throwable next, string file = __FILE__, size_t line = __LINE__) {
>      super(msg, file, line, next);
>    }
> }
>
> <<-D---
>

---D->>
class MyException : Exception {
    mixin GenericExceptionConstructors;
}
<<-D---

> The other think that I'd really like to see is an actual declaration for the user of a function to see what exceptions can be thrown - also inferred and checked by the compiler. In Java you cannot compile a function that throws some (checked) exception and doesn't declare that like this:
>
> ---Java->>
>
> void foo() throws MyException {
>    throw new MyException("test");
> }
>
> <<-Java---
>
> This way you, as the author, are always aware of which Exceptions you handle inside the function and which may escape. This escalates to callers of the function as well, so that in the end the public API has an exact list of possibly thrown exceptions that the user must handle.
> I have around a dozen different exceptions in a hierarchy and a few nested function calls. It's a maintenance horror to keep the DDoc up to date about thrown Exceptions. It also doesn't check the spelling or offers a link to the Exceptions.
>
> ...
>
> I know that the Java way isn't perfect, because some lazy people write dummy exception handlers to silence the errors,
> but its a worse solution to _not_ notify the user of a function, that it potentially throws exceptions, I think. So I
> wish D was explicit about thrown Exceptions.
>

Well, any scheme for explicit exception annotations I can think of
is either unsound or impractical. What would you suggest concretely?
August 12, 2012
On 8/11/2012 8:02 PM, Marco Leise wrote:
> I know that the Java way isn't perfect, because some lazy people write dummy
> exception handlers to silence the errors, but its a worse solution to _not_
> notify the user of a function, that it potentially throws exceptions, I
> think. So I wish D was explicit about thrown Exceptions.



Read this and see if you change your mind:

http://www.mindview.net/Etc/Discussions/CheckedExceptions/

Anyhow, that article is why D does not have exception specifications. Also, please note that C++ dropped exception specifications.
August 12, 2012
On Saturday, August 11, 2012 21:27:43 Walter Bright wrote:
> Anyhow, that article is why D does not have exception specifications. Also, please note that C++ dropped exception specifications.

Though it should be noted that exception specifications are _far_ worse than checked exceptions, because they're checked at runtime instead of compile time, and they kill your program if they fail. So, instead of all of the problems that you get with checked exceptions, you get your program killed at runtime when you don't get your code quite right.

I think that you're going to have a hard time finding _anyone_ who actually understands what C++'s exception specifications do and still thinks that they're a good idea, whereas you _will_ find people who fully understand checked exceptions and still think that they're a good idea.

- Jonathan M Davis
August 12, 2012
I read both articles and while Bruce Eckel's text read a bit like repeated "swallow exception" to "avoid reams of code" I found the interview insightful. Both aren't entirely negative on checked exceptions and Hejlsberg actually wants them:

  [Anders Hejlsberg]: "And so, when you take all of these issues, to me it just seems more thinking is needed before we put some kind of checked exceptions mechanism in place for C#. But that said, there's certainly tremendous value in knowing what exceptions can get thrown, and having some sort of tool that checks."

The arguments against the Java model were:

1) The programmer, annoyed by the compiler, swallows exceptions with empty catch clauses and forgets about them.

I think _if_ the intention is to get back to it later, you can always write "// TODO: handle the missing icon, by loading a stock icon from the OS". On the other hand, if you just don't want to declare the thrown exception, then this is wrong thinking in my opinion. Usually when I am in this situation in Java it makes me think about the error handling: Can this error be handled gracefully? If so, right here or should it bubble up? Where is the right level to handle it? At the end of this process I have the positive feeling that I got the error handling right.

2) Versioning; a change in a function may add a thrown exception, breaking client code. Often those clients want to ignore any exceptions (and pass them on).

Ok, accepted. The client code would have to change its "throws" list for no perceivable benefit.

3) Declaring the thrown exception doesn't scale well when you call into multiple subsystems that each throw different exceptions, where you would end up declaring dozens of thrown exceptions.

I frankly have to say that I never worked on that big projects, that I had to declare 40 thrown exceptions. And the question may be asked if you should just wrap the exception into another at that point, because you obviously reached a granularity at which the finer details of the sub system failures have become secondary.


So does it all boil down to the potentially long and cascading list of "throws"?
This is not a first grade language issue, I realize that. It's just when you come across it and find yourself documenting the thrown exceptions in DDoc where they aren't checked or anything, it cries for a solution. The solution current languages take seems to be "let the exceptions slip through, more often than not you don't handle them anyway".
How can we reap all the benefits, but avoid the manual listing of all thrown exceptions?

-- 
Marco

August 12, 2012
Am 12.08.2012 08:22, schrieb Marco Leise:
> I read both articles and while Bruce Eckel's text read a bit like repeated "swallow exception" to "avoid reams of code" I found the interview insightful. Both aren't entirely negative on checked exceptions and Hejlsberg actually wants them:
>
>    [Anders Hejlsberg]: "And so, when you take all of these issues, to me it just seems more thinking is needed before we put some kind of checked exceptions mechanism in place for C#. But that said, there's certainly tremendous value in knowing what exceptions can get thrown, and having some sort of tool that checks."
>
> The arguments against the Java model were:
>
> 1) The programmer, annoyed by the compiler, swallows exceptions with empty catch clauses and forgets about them.
>
> I think _if_ the intention is to get back to it later, you can always write "// TODO: handle the missing icon, by loading a stock icon from the OS". On the other hand, if you just don't want to declare the thrown exception, then this is wrong thinking in my opinion. Usually when I am in this situation in Java it makes me think about the error handling: Can this error be handled gracefully? If so, right here or should it bubble up? Where is the right level to handle it? At the end of this process I have the positive feeling that I got the error handling right.
>
> 2) Versioning; a change in a function may add a thrown exception, breaking client code. Often those clients want to ignore any exceptions (and pass them on).
>
> Ok, accepted. The client code would have to change its "throws" list for no perceivable benefit.
>
> 3) Declaring the thrown exception doesn't scale well when you call into multiple subsystems that each throw different exceptions, where you would end up declaring dozens of thrown exceptions.
>
> I frankly have to say that I never worked on that big projects, that I had to declare 40 thrown exceptions. And the question may be asked if you should just wrap the exception into another at that point, because you obviously reached a granularity at which the finer details of the sub system failures have become secondary.
>
>
> So does it all boil down to the potentially long and cascading list of "throws"?
> This is not a first grade language issue, I realize that. It's just when you come across it and find yourself documenting the thrown exceptions in DDoc where they aren't checked or anything, it cries for a solution. The solution current languages take seems to be "let the exceptions slip through, more often than not you don't handle them anyway".
> How can we reap all the benefits, but avoid the manual listing of all thrown exceptions?
>

I have a large experience in JVM and to some extent .NET enterprise projects. These projects have a multi-site component usually in three
development sites, scattered around Europe and Asia, having from 30
up to 300 developers on project.

To keep costs per team member low, not everyone on the projects is a top coder, many are on their first or second big project.

Throws in Java method declarations are reduced to "throws Exception", or
"throws RuntimeException" with the real exception being wrapped in a RuntimeException.

Many places where the exceptions occur are handled like

try {
  // ...
} catch (Exception e) {
 e.printStackException(); //TODO: fix later (Like you describe)
}

Sure we try to fight against this type of code, but at the end of the day, there are many other issues to solve, and this type of code gets low priority as fixing it does not make money.


Checked exceptions are a failed experiment, and I surely hope that D does not get them.

It is a bit like the arguments about manual memory management, sure good
coders are able to make proper use of such abstractions, but in real life, projects seldom have real good coders on their teams. And when they have them, there are many other issues to take care of.

--
Paulo

August 12, 2012
Paulo Pinto:

>And when they have them, there are many other issues to take care of.<

This is a bad argument because there are always other issues to take care of. Even if a firm buys an artificial intelligence able to self-write all the code, I am sure people in that firm will keep saying "we have many other issues beside writing code!".

Bye,
bearophile
August 12, 2012
On Sunday, 12 August 2012 at 11:48:23 UTC, bearophile wrote:
> Paulo Pinto:
>
>>And when they have them, there are many other issues to take care of.<
>
> This is a bad argument because there are always other issues to take care of. Even if a firm buys an artificial intelligence able to self-write all the code, I am sure people in that firm will keep saying "we have many other issues beside writing code!".
>
> Bye,
> bearophile

Sure it is, but I've learned that if you live in the Fortune 500 corporation world, it not worth fighting against it.

Actually there are a few talks in InfoQ about this type of issue.

http://www.infoq.com/presentations/Stop-Refactoring
http://www.infoq.com/presentations/Who-Ever-Said-Programs-Were-Supposed-to-be-Pretty

--
Paulo

« First   ‹ Prev
1 2 3 4 5