| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12
Comments:
<0> it greatly complicates your code because now you have to know everything that is thrown from what you're doing so that if you don't expect to handle it locally within your function, you can let the exception p***
<0> it may be questionably useful for a language like java that does compile time checking (last i recall, doesn't Java force things on the user with respect to exception specifiers?)
<1> ugh rand() is so, so, so bad
<2> lol
<2> poker?
<3> mozai I undersdand what you "expect" I'm saying that you're unlikely to KNOW for certain
<0> terminate = unhandled, that is
<0> which calls terminate by default
<0> (usually)
<0> unexpected() that is
<0> sigh
<0> C# rots the brain!
<1> peterhu ever had to reimplement the rand function because the ANSI one is insufficient?
<0> can't say that i have
<4> doesn't the compiler enforce the case where if the method throws something it is not advertsing it generates a compilation error?
<0> doesn't boost have a PRNG?
<1> prolly
<0> mozai, no
<5> mozai i doubt it could know in most cases
<1> but I had to do some maths crunching to realise why my simulations were biased
<1> due to rand
<0> An implementation shall not reject an expression merely because when executed it throws or might throw an exception that the containing function does not allow.
<0> well, vic can bitch at him in private i guess heh
<6> hmm to thread or to fork? that is the question..
<2> what is the contact.. that is the question
<0> depends on the platform
<2> *context
<6> on linux
<6> context is .. handling socket connections.. processes/threads don't really need to share data but i like the idea of threading since it's more mortable..
<1> depends what you need too
<6> portable
<7> peterhu: yup, java obeys you to handle exceptions when calling a function declaring throws, IDEs even annotate that before you compile
<6> java obeys you?
<6> java is like an eastern wife
<0> not even my wife does that!
<0> BA DUM CHA
<6> heh
<6> melfar: do you mean requires you?
<7> well yes, isn't it the right word I used?
<6> ok i think i'll thread.. pthreads are more portable that forkage
<0> mozai, in case you missed what i pasted
<0> An implementation shall not reject an expression merely because when executed it throws or might throw an exception that the containing function does not allow.
<2> BrainySmurf: ever considered in-process multiplexing/
<2> (eg: select etc)
<6> Tamama, hmm. i could do that but in practice that always has slower throughput than threading since lots of the stuff i do per thread is io-bound
<3> mozai exception specifications aren't working out like the standards committee hoped using them might lead you into a false sense of security
<2> ehm.. slower throughput?
<3> BrainySmurf and boost::threads even moreso
<6> Tamama, yes.
<6> yeah boost::threads is awesome
<4> peterhu: I did indeed miss it. I am trying to understand what it means.
<3> mozai what benefit do you perceive in using an exception specification?
<6> i thought in C++ exception specs were next-to useless?
<0> it means the compiler will accept an expression it knows will not meet the exception specification requirements of a function
<0> so basically, you'll only get runtime errors in the form of unexpected()
<4> peterhu: I see
<8> exceptions rock
<8> I love expcetions
<8> exceptions
<8> love them.
<4> vawjrwk: well, if I know that the method will only throw a "NumberFOrmatExpcetion" i won't catch a "StringLengthExpcetion"
<8> let the error propagate to where it's cared about.
<3> mozai but you DON'T know
<6> but the kicker is, if you use an exception spec in C++, be damned sure nothing else will be thrown from any code you call or else your program will abort() beautifully..
<3> that's what I've been trying to tell you
<0> mozai, he means that for you to really know the exceptions your function throws, you need to know the transitive closure of all the throws of all the functions your function calls, not a small feat most of the time
<6> exception specs are awesome for client code, but really require careful planning for the component writer
<4> if the code my method is using throws a different expetion from the one it is advertsing, IT should handle it
<3> or are you catching all possible exceptions and translating them into yours
<8> well
<8> you could just do a catch(...)
<0> ack
<0> evil
<8> and then rethrow your own exception type
<0> catch (...) catches SEH
<8> SEH?
<0> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/structured_exception_handling.asp
<3> I'm baffled that someone didn't make an SEH cl*** somewhere and encapsulate all the **** you know from one
<6> mozai, well, if all the libs you call into are that well designed to have throw() clauses, then great
<0> catch (...) only belongs in one place
<0> a top level exception handler
<8> that's where mine always goes
<4> Brainy: Yes, they all do. I am designing the framework.
<0> or if you want to play some stack overflow trickery or some such
<3> peterhu it's the FIRST thing I would have done if I'd been in charge of the library
<6> mozai, ah. then very good. use exception specs! they really make writing client code less of a bitch
<3> I'm willing to wager that mozai actually doesn't know all the things that can be thrown
<4> yes, that is what I though too, but people are telling me it is a useless feature, I just want to understand why :)
<8> but, there might be a case where you don't want any exception info finding its way out of your function
<8> except of your own type
<3> mozai because it's likely that you haven't looked closely at all the standard library stuff you're using
<8> even if he DOES know all of teh things that can be thrown in the underlying libraries he's using
<7> what if it's some of the standard exceptions , like bad alloc or something? do you need to specify themj also?
<8> those libs might change.
<0> agreed
<3> Noidea right
<3> melfar yes
<0> personally, i'd rather have an undocumented exception boiled up from some function i call than an unexpected() call, but that's just me.
<6> due to all of the considerations mentioned above, i usually don't use exception specs.. they are hard to get right...
<3> peterhu me also
<8> unexpected isn't so bad
<8> it points your debugger at the right place at least :)
<4> how do you guys do the exception catch if you don't know the possible thrown exceptions types?
<8> I usually wrap my top level exception handler in something like
<8> #ifndef DEBUG
<0> i'd consult the documentation
<3> mozai I handle the ones I know how to
<8> so I've got no top level handler when I'm in debug mode.
<4> what if your method is only doing something that doesn't use no external libs, and will never throw an exption type your code is trying to catch?
<8> then the debugger takes me to where it was thrown
<3> mozai doesn't happen
<8> rather than me getting a nice error message as my app closes.
<8> the newer g++s added a nice feature
<8> if you have no handler for an exception
<3> oh ****, now what
<8> as the app aborts
<8> it will call what() and print the results
<8> so you get the debugger pointed correctly
<8> AND the message
<8> sweet
<4> vawjrwrk: ok....I have lots of scenarios where it might happen, I cannot just go catching any excpetion that I think my called method might throw
<3> yes, that's very nice
<6> mozai, yeah if your code doesn't call into any libs then you are ok. but there is lots of implicit calling into libs.. like when you new() an object, delete it, etc
<3> even sometimes when you simply instantiate an object
<6> i like to name my exception stringify methods wtfomglmao()
<8> and, apparently hardware exceptions
<8> like DIV by 0
<8> and stack overflow
<4> vaw: yes, but I have methods like validate, that only does ( if param < min_range throw OutOfRangeException )
<6> mozai, i think if you are careful you can design a lib/component that is pretty exception safe and sticks to its contract with client code.. it's a noble aim and go for it
<0> hmm, i've eaten too many of the spring (Easter maybe?) colored M&M's my wife put out in a dish in the hall
<4> all right, I will think about it and see what i'll do. I mean, I understand vaw's point of view.
<6> just because it's hard to do in C++ doesn't mean it's impossible.. it's just a real pain
<0> she bought this really nice foyer table which we have candles and the candy dish on in the hallway. original price $150. purchased for $14.95
<0> she's a good sales person and it works in reverse
<9> smells like _____
<6> kimchi?
<3> mozai and param is p***ed in by reference?
<7> teen spirit?
<0> i've actually never had kim chi
<0> (one word or two?)
<8> "Bond is fantasy, there's no real substance to it," he said. "It's a figment of imagination. ... (It's) sort of crazy, you know, a spy who is recognized wherever he goes. Spies ain't like that."
<8> heh
<8> That's Roger Moore's quote, btw.
<4> vawjrwrk: param is actually a member of the object
<0> i looooove pho, now that's good stuff
<3> the engineer I was working with in Tucson married a lady of Korean background. she make great kimchee
<4> it was just an example, i used the wrong name
<3> I asked if it was p***ed by reference that's all
<6> peterhu, i thought you were azian?
<0> heh, i saw CIA job adds on monster for "clandestine operations"
Return to
#c++
or
Go to some related
logs:
landa taz-zejt
#linux
chlorox inhalation
#chatzone
Malakist
mythweb streaming ubuntu
#MissKitten
#AllNiteCafe
Sasasti
itf8
|
|