| Time |
S |
Nick |
Message |
| 03:01 |
|
|
sfisque joined ##javaee |
| 03:02 |
|
|
sfisque1 joined ##javaee |
| 03:43 |
|
|
SoniEx2 joined ##javaee |
| 10:19 |
|
|
onr left ##javaee |
| 13:06 |
|
pdurbin |
If I want to replace an EJBException with a non-runtime exception, which one should I use? Just "Exception"? In this case we are parsing a string and making sure it has a colon and a slash in it: https://github.com/IQSS/dvn/blob/d38b9c7cc9c5347236fd7fd971e1648f465fbaea/src/DVN-EJB/src/java/edu/harvard/iq/dvn/core/study/StudyServiceBean.java#L1501 |
| 13:23 |
|
|
Naros joined ##javaee |
| 13:41 |
|
pdurbin |
woof, too long for me to read right now: Best practices in EJB exception handling - http://www.ibm.com/developerworks/java/library/j-ejbexcept/index.html |
| 13:42 |
|
pdurbin |
I did take a quick glance at http://stackoverflow.com/questions/1581600/why-throwing-an-ejbexception-is-a-recommended-practice |
| 14:52 |
|
|
kobain joined ##javaee |
| 14:55 |
|
sfisque1 |
pdurbin: how about a ParseException |
| 14:55 |
|
sfisque1 |
one thing to keep in mind though is if this error is coming from inside a transaction you need to throw ejbexception so that the JTA semantics are maintained |
| 14:57 |
|
* pdurbin |
looks at http://docs.oracle.com/javase/6/docs/api/java/text/ParseException.html ... which makes a lot of sense |
| 14:57 |
|
pdurbin |
sfisque1: but thanks for the JTA tip |
| 14:58 |
|
pdurbin |
for now I'm just doing "find usages" and making sure I surround that method with a try catch since I'm not forced to (EJBException being a RuntimeException and all) |
| 16:02 |
|
whartung |
I've never thrown an EJBException in my life (not consciously) |
| 16:07 |
|
sfisque |
i have a few times, basically caught an exception, wrapped it in an ejbEx and rethrew |
| 16:07 |
|
whartung |
I just wrap in a RuntimeException -- I'm sure if I swapped all of those to EJBException there would be no difference :) |
| 17:11 |
|
pdurbin |
I'm realizing the other thing I could do is replace "throw new EJBException..." with "return null" |
| 17:21 |
|
sfisque |
depends. is the outcome "exceptional" or is it a feasible outcome of the workflow |
| 17:22 |
|
sfisque |
too often i see devs use exception handling as execution dispatch (blech) |
| 17:22 |
|
sfisque |
exceptions are not "outcomes", they are "failure points" |
| 17:24 |
|
SoniEx2 |
http://plumbr.eu/blog/throwing-exceptions-slow-and-ugly |
| 17:24 |
|
SoniEx2 |
I saw that on reddit yesterday... or 2 days ago... something like that... |
| 17:29 |
|
sfisque |
aye. exceptions have a fair amount of overhead. you don't want to throw or catch them "needlessly" |
| 17:35 |
|
whartung |
yea, exceptions are exceptions. They are "I can't handle this, Calgon, take me away!" |
| 17:36 |
|
whartung |
anyone ever do anything with JAX WS and MTOM? |
| 17:36 |
|
sfisque |
i'mve used jaxws, but not mtom |
| 17:37 |
|
whartung |
just wonder the differences between MTOMFeature and setMTOMEnabled. I think it's an either/or thing. |
| 17:37 |
|
whartung |
but I have code here that uses both |
| 17:37 |
|
whartung |
MTOM DAMNIT! |
| 17:37 |
|
whartung |
for a client |
| 17:38 |
|
whartung |
oh well, no worries, tabling it for monday. |
| 17:40 |
|
pdurbin |
heh. Calgon |
| 17:41 |
|
pdurbin |
so simply returning null makes sense? |
| 17:41 |
|
sfisque |
depends |
| 17:41 |
|
pdurbin |
heh. sure :) |
| 17:41 |
|
sfisque |
that's a question for you, the requirements, and the consumers of the method |
| 17:42 |
|
whartung |
The simple point is |
| 17:42 |
|
pdurbin |
I'm a consumer of the method. And I wish it would have told me it might throw an exception :) |
| 17:42 |
|
whartung |
well that's what checked exceptions are for, but I loathe those as a rule. |
| 17:43 |
|
whartung |
For example, I find the parseInteger commands that throw exceptions for bad data rather annoying. |
| 17:43 |
|
whartung |
I appreciate that converting "abcd" in to 0 can also be problematic. |
| 17:44 |
|
pdurbin |
yeah. I don't want to introduce an anti-pattern. maybe the method should just return null rather than a ParseException in certain cases |
| 17:44 |
|
whartung |
but I think it would be better if there was another method that returns a state instance. with a short cut method that just returns zero. (or MININT, or some other target number). |
| 17:45 |
|
whartung |
because 99.999% of the time, by the time I'm parsing for value, it's "going to work" |
| 17:45 |
|
pdurbin |
but I did try changing EJBException to ParseException (didn't commit it) and it does what I want. But we'd have to change code in a bunch of places because suddenly there's a check exception |
| 17:45 |
|
whartung |
yup |
| 17:45 |
|
sfisque |
i would say, if you are returning null because "i didnt find anything", that should be fine. if you're returning null because "the string was unparsable" , then i'd say the exception is valid (unless you expect a high percentage of "bad data", then maybe some return value that indicates that state |
| 17:45 |
|
whartung |
\o/ |
| 17:46 |
|
pdurbin |
yeah. makes sense |
| 17:46 |
|
pdurbin |
again for now, I'm just catching the RunTimeException whenever I call the method |
| 17:47 |
|
whartung |
well that's my point, specifically about checked exceptions. most of the time, I simple CAN'T handle the exception, whatever it might be. if I'm calling parseInt, odds are good if it throws an parsing exception, I can't do anything about it anyway. |
| 17:48 |
|
sfisque |
aye. my main point is more to the concept of "i'm parsing 'arbitrary data that can be [bad] quite often", do i really want to throw exceptions or return state codes that tell the next layer up, "hey, fix the data, it's damaged" |
| 17:48 |
|
sfisque |
like user inpuyt |
| 17:48 |
|
sfisque |
or a data feed with noise |
| 17:49 |
|
whartung |
yea, discovering bad data is part of the parsing contract. |
| 17:50 |
|
pdurbin |
in my case the potentially bad data is coming in from a user on a RESTful API I'm implementing. I'm catching the EJBException and letting them know they sent bad data |
| 17:50 |
|
pdurbin |
s/on/of/ |
| 17:50 |
|
whartung |
yea, that's fine pdurbin that works |
| 17:50 |
|
pdurbin |
ok. good |
| 17:50 |
|
sfisque |
aye. in that case, the exception would be meaningless to the end user. giving them some "feedback" is better than just "it blew up, deal with it" |
| 17:51 |
|
whartung |
just send it back with a 400 error |
| 17:52 |
|
sfisque |
but i guess with seperation of concerns, the ejb doing the parsing can return the exception with a message, and the overlaying controller/endpoint can extract the message or handle the exception however it wants |
| 17:52 |
|
pdurbin |
yeah. comes back as HTTP/1.1 400 Bad Request |
| 17:52 |
|
sfisque |
or have a subclass of ParseEx with an additional payload that gives some failure code to the next layer up (like garbage, badformat, null string, etc.) |
| 20:39 |
|
|
SoniEx2 joined ##javaee |
| 20:52 |
|
|
SoniEx2 joined ##javaee |
| 21:08 |
|
|
SoniEx2 joined ##javaee |
