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 m
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
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) {
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
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, becaus
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 th
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
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 "w
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 al
Perhaps a workable compromise is to make ddoc able to
automatically output the throws list.
That way, we don't have the hassle of checks, but we do have a
maintained list at relatively no hassle.
If you call a function to which the source code isn't available,
ddoc can just point you toward
On Sun, 12 Aug 2012 16:33:39 +0200, Adam D. Ruppe
wrote:
Perhaps a workable compromise is to make ddoc able to automatically
output the throws list.
That way, we don't have the hassle of checks, but we do have a
maintained list at relatively no hassle.
If you call a function to which
On Sunday, August 12, 2012 16:33:39 Adam D. Ruppe wrote:
> Perhaps a workable compromise is to make ddoc able to
> automatically output the throws list.
>
> That way, we don't have the hassle of checks, but we do have a
> maintained list at relatively no hassle.
That's both a good idea and bad id
On 8/12/2012 4:48 AM, 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 p
Am Sun, 12 Aug 2012 14:34:58 +0200
schrieb "Paulo Pinto" :
> 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
>
On Sunday, 12 August 2012 at 03:02:50 UTC, Marco Leise wrote:
I just got a bit frustrated and wanted to say that I like
working with Exceptions in Java a lot more.
I don't. When writing a simple command line program, when there's
an error, it usually means the user messed up and I can't
recov
Am Mon, 13 Aug 2012 10:00:31 +0200
schrieb "Nathan M. Swan" :
> On Sunday, 12 August 2012 at 03:02:50 UTC, Marco Leise wrote:
> > I just got a bit frustrated and wanted to say that I like
> > working with Exceptions in Java a lot more.
>
> I don't. When writing a simple command line program, whe
Am Mon, 13 Aug 2012 10:50:47 +0200
schrieb Marco Leise :
> I don't know how many there are who think like me. Your @throws proposal for
> example could be used to tell the compiler that I want Java style checked
> exceptions for this function and have the compiler check that I listed them
> all
I think I should clarify some things up front.
o First of all, to be able to add @throws to a function at any point,
means that the compiler would internally replace the flag 'isnothrow'
with a list of thrown exceptions. That is not much different from what
there is now and would be part of
On Sun, 12 Aug 2012 22:01:49 +0100, Jonathan M Davis
wrote:
On Sunday, August 12, 2012 16:33:39 Adam D. Ruppe wrote:
Perhaps a workable compromise is to make ddoc able to
automatically output the throws list.
That way, we don't have the hassle of checks, but we do have a
maintained list at
On 2012-08-13 12:31, Regan Heath wrote:
I wonder if it might be possible to make an intellisense style GUI/IDE
tool/plugin which could determine all exceptions thrown either by direct
code inspection or ddoc inspection (when source is unavailable) such
that it could actually build a complete lis
On 12-Aug-12 07:02, 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) {
s
On 08/13/2012 05:32 PM, Dmitry Olshansky wrote:
I think the true cryptonite that melts "checked exceptions" to a pile of
green goo is templated code:
So (*yawn*) tell what kind of exception specification the following
function should have:
auto joiner(RoR, Separator)(RoR r, Separator sep);
Ho
On 13-Aug-12 19:50, Timon Gehr wrote:
On 08/13/2012 05:32 PM, Dmitry Olshansky wrote:
I think the true cryptonite that melts "checked exceptions" to a pile of
green goo is templated code:
So (*yawn*) tell what kind of exception specification the following
function should have:
auto joiner(RoR
On 08/13/2012 05:54 PM, Dmitry Olshansky wrote:
On 13-Aug-12 19:50, Timon Gehr wrote:
On 08/13/2012 05:32 PM, Dmitry Olshansky wrote:
I think the true cryptonite that melts "checked exceptions" to a pile of
green goo is templated code:
So (*yawn*) tell what kind of exception specification the
On Monday, 13 August 2012 at 10:02:23 UTC, Marco Leise wrote:
Thoughts ?
I like this idea - you can use checked exceptions, but you aren't
forced.
Though I think private and free functions should by default just
use @throws(Exception). Not using @throws is like saying "I don't
pay attentio
Am Mon, 13 Aug 2012 19:54:47 +0400
schrieb Dmitry Olshansky :
> On 13-Aug-12 19:50, Timon Gehr wrote:
> > On 08/13/2012 05:32 PM, Dmitry Olshansky wrote:
> >>
> >> I think the true cryptonite that melts "checked exceptions" to a pile of
> >> green goo is templated code:
> >>
> >> So (*yawn*) tell
Am Mon, 13 Aug 2012 20:17:12 +0200
schrieb "Nathan M. Swan" :
> On Monday, 13 August 2012 at 10:02:23 UTC, Marco Leise wrote:
> > Thoughts ?
>
> I like this idea - you can use checked exceptions, but you aren't
> forced.
>
> Though I think private and free functions should by default just
> us
On Monday, 13 August 2012 at 15:32:45 UTC, Dmitry Olshansky wrote:
So (*yawn*) tell what kind of exception specification the
following function should have:
auto joiner(RoR, Separator)(RoR r, Separator sep);
auto joiner(RoR, Separator)(RoR r, Separator sep)
throws(?);
On Tuesday, 14 August 2012 at 23:13:07 UTC, Mehrdad wrote:
On Monday, 13 August 2012 at 15:32:45 UTC, Dmitry Olshansky
wrote:
So (*yawn*) tell what kind of exception specification the
following function should have:
auto joiner(RoR, Separator)(RoR r, Separator sep);
auto joiner(RoR, Separa
On Monday, 13 August 2012 at 15:32:45 UTC, Dmitry Olshansky wrote:
Back to Java: what is I find strange is the lack of sensible
tools to do transactional or exception safe code within the
language. No RAII objects or just at least any kludge to
reliably register cleanup/rollback, only "good" ol
On Tuesday, 14 August 2012 at 23:21:32 UTC, Mehrdad wrote:
Or even better:
auto joiner(RoR, Separator)(RoR r, Separator sep)
throws(auto);
That way it's easy enough for the programmer to make the
compiler shut up (it's certainly easier than swallowing the
exception), while allowing h
On Sunday, 12 August 2012 at 04:36:22 UTC, Jonathan M Davis wrote:
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 excep
On Sunday, 12 August 2012 at 06:22:37 UTC, Marco Leise wrote:
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 want
On Monday, 13 August 2012 at 08:00:33 UTC, Nathan M. Swan wrote:
On Sunday, 12 August 2012 at 03:02:50 UTC, Marco Leise wrote:
I just got a bit frustrated and wanted to say that I like
working with Exceptions in Java a lot more.
I don't. When writing a simple command line program, when
there'
On Wednesday, 15 August 2012 at 17:44:14 UTC, SomeDude wrote:
Or you could have told him HOW he messed up. By just throwing
an Exception, you are not helpful at all, you are just telling
that he is an ass and that he will be punished for that. Or
maybe he will curse you thinking that your progr
I had times when I missed the Java-style Exception handling.
First time I just the D sockets exceptions was thrown during
runtime. The Library Reference didn't tell my anything about
exceptions neither did the compiler.
This could've been avoided with documentation stating which
exceptions can
Am Wed, 15 Aug 2012 19:44:13 +0200
schrieb "SomeDude" :
> On Monday, 13 August 2012 at 08:00:33 UTC, Nathan M. Swan wrote:
> > Perhaps an annotation might be nice, as long as it doesn't
> > force catching:
> >
> > void buggyFunction(string file, int exception)
> > @throws(StdioException);
>
> I
Am Thu, 16 Aug 2012 15:11:41 +0200
schrieb "Manipulator" :
> I had times when I missed the Java-style Exception handling.
>
> First time I just the D sockets exceptions was thrown during
> runtime. The Library Reference didn't tell my anything about
> exceptions neither did the compiler.
> This
Am Mon, 13 Aug 2012 19:32:38 +0400
schrieb Dmitry Olshansky :
> I think the true cryptonite that melts "checked exceptions" to a pile of
> green goo is templated code:
>
> So (*yawn*) tell what kind of exception specification the following
> function should have:
>
> auto joiner(RoR, Separator
On Thursday, 16 August 2012 at 10:37:01 UTC, Kagamin wrote:
On Wednesday, 15 August 2012 at 17:44:14 UTC, SomeDude wrote:
Or you could have told him HOW he messed up. By just throwing
an Exception, you are not helpful at all, you are just telling
that he is an ass and that he will be punished f
40 matches
Mail list logo
